the kiZZ notes » geek stuffs

unit testing is teh suck, or is it?

kiZZ kiZZ — Tue, 06 May 2008 15:52:36 +0000

I was reading about unit testing and I came across Wil‘s blog article: Unit testing is teh suck, which was dated back in 2005. That title looked like it was asking for a flame war (as it happened) and it sounded very interesting to me right after I recently discovered the value in Test Driven Development.

The article was great, with many valid point. One particular comment from Shalev probably sums up my view:

I feel as if a great light has finally dawned upon me. The dark hypocrisy’s of people yelling “Don’t Repeat Yourself!”, and then turning around and writing their application twice have finally given way to the light of a new way. The fact is that code that fully tests an application will always be bigger than the application code itself. This has always grated against the grain of my least-code-possible programmer soul. I thank you for finally validating what I others claimed a defect in my programming nature.

The least-code-possible programmer soul, huh? That’s my philosophy all along.

So what’s my take on unit testing now? To test or not to test? I would say, be flexible.

From another of Wil’s article (forgot which one), he said something along the lines of “When people first learned objective languages, they go and create a God class, which inherits like 40 subclasses each with probably a couple of lines of code difference” That’s right, that’s probably also the case for unit testing: when people first heard of unit tests, they became advocates. (For the case of unit test, perhaps more people run away than to become advocates, but you get the point)

Does that mean objective languages and OO are teh suck? No! It’s the master programmer’s decision as to when to use what tools and when to not use them. These kinds of experience, instead of things like which language 0wnz which language, are what separate generic programmers from the true masters.

Unit testing in general is a good idea, but it becomes an anti-pattern when one gets restricted by it: waste too much time writing tests other than writing actual code, obsessing over than 10% of code coverage which is just a number (as high-scores from video games) Similarly, I think completely ditching unit tests is a waste of such valuable tools.

In the end, there is no need for black-and-white thinking here, just do what feels right at the moment based on your experience.

K2HttpRequest: asynchronous HTTP request using IWebBrowser2

kiZZ kiZZ — Mon, 05 May 2008 15:34:01 +0000

In my previous battle against Internet Explorer add-on (BHO), I discovered some valuable (and scarce) resources to my aid. Pete‘s TinyBHO and CPeteHttpRequest probably saved the most of my day.

Then I realized a problem: for the browser add-on that I was writing, I would have to fetch a Web page from a server that requires user login. Under typical usage scenarios, the users are assumed to have logged in the server in a previous session, so the Web server will authorize the user from cookies. However, using WinHttp on which CPeteHttpRequest is based on, there seems to be no (simple) ways to obtain the user’s cookies and embed it in the HTTP request. I couldn’t find another piece that is as simplistic as CPeteHttpRequest and also able to deal with my problem at hand.

So I wrote one myself.

K2HttpRequest has the usage of:

1
2
3
4
5
6
7
8
9

K2HttpRequest request;

// Synchronous
wstring innerHTML = request.request ( L"http://www.google.com" );

// Asynchronous
void foo ( wstring innerHTML ){}
request.SetOnComplete ( foo );
request.request ( L"http://www.google.com", true );

K2HttpRequest uses IWebBrowser2 internally, which means it opens a new Internet Explorer instance under the hood and loads the Web page with it. Thus, the server will receive login cookies as if the user visited the Web page. It will fetch the Web page at the specified URL and return the HTML in the <body> element (I actually intended return the whole <html> element but I can’t find an easy way to do it, as IHTMLDocument2 doesn’t have get_innerHTML())

This is still a very preliminary version, and will probably improve as my COM/ATL skills improve some day.

Download K2HttpRequest(source code ~5KB, Visual C++ 2008)

(Update: The asynchronous part of this doesn’t work very well. I didn’t know COM enough to use Marshalling when I wrote this version. I’ll probably update this some day. If you want to get the asynchrounous part working, you’ll probably have to add in marshalling yourself :p)

why Test Driven Development (TDD) matters

kiZZ kiZZ — Fri, 02 May 2008 09:56:16 +0000

Like many programmers who first heard of concepts of Test Driven Development (TDD), I was like “What the heck? Yet more code to write for something that won’t produce end user output?”. I’ve been puzzling for quite some time to get myself accepting this concept, because Code Complete mentioned it so I thought it must have been a good thing (very great book by the way, every serious programmer should read it).

I sometimes write unit tests and I think unit tests are very useful in some tricky areas. It’s just that I haven’t been motivated enough to try TDD (test first then write code).

Then today I realized how TDD is a natural progression for people writing unit tests. TDD promotes clean OO designs. In short, I can even almost say that “If you can test it, it has good design”.

I came across this realization while trying to write unit tests for this piece of JavaScript code afterwards:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

/**
* Existing (bad design) JavaScript
*/

var Gateway =
{
ajaxGet: function(){},
};

// AccountManager uses Gateway, this is the “class” we want to test in this example
var AccountManager =
{
get: function ( id, onComplete )
{
Gateway.ajaxGet ( “/accounts/” + id , function ( profile ){ onComplete ( profile ); } );
}
}

That’s intuitive enough, huh? As much as I thought it was, until I tried to write unit tests for it using JsMock, which has the typical usage of:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

/**
* Typical JsMock usage example
*/

var mockControl = null;

function Worker(){}
Worker.prototype<span> span>=
{
doWork: function(){}
}

function setUp()
{
mockControl = new MockControl();
}

function testWorker()
{
var workerMock = mockControl.createMock ( Worker );
workerMock.expects().doWork();
workerMock.doWork();
workerMock.verify();
}

With the code I have written, it is impossible to do testing with JsUnit:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

/**
* Attempt to test my existing code with JsMock (in JsUnit)
*/

var mockControl;

function setUp()
{
mockControl = new MockControl();
}

function testAccountManagerGet()
{
var accountManagerMock = mockControl.createMock ( Gateway );

// ERROR! mockControl.createMock() only accepts a class name,
// but Gateway is a variable name

}

So to make things compatible with JsUnit, I had to rewrote the whole stuff:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

/**
* My revised JavaScript compatible with JsUnit
*/function Gateway (){}

Gateway.prototype =
{
ajaxGet: function(){}
}

function AccountManager ( gateway )
{
this.gateway = gateway;
}

AccountManager.prototype =
{
get: function ( id )
{
this.gateway.ajaxGet ( “/accounts/” + id );
}
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

/**
* JsUnit tests for my revised code
*/var mockControl = null;

function setUp()
{
mockControl = new MockControl();
}

function testAccountManagerGet()
{
// OK now, because Gateway is a class
var gatewayMock = mockControl.createMock ( Gateway );

var accountManager = new AccountManager ( gatewayMock );

// test fixtures
var id = “kizzx2”;

gatewayMock.expects().ajaxGet ( “/accounts/” + id );
accountManager.get ( id );

mockControl.verify();
}

The above changes might look redundant at first and not so intuitive. But then I came to think of it, it removed the dependency between my AccountManager class and the Gateway class. I wasn’t quite aware of such anti-pattern until JsUnit/JsMock brought it to my attention.

If I had used TDD in the first place, where I would have to write the tests first, it would have enforced me to use clean OO models to design things. Now I think that’s a pretty solid justification for using TDD.

making an Internet Explorer add-on

kiZZ kiZZ — Thu, 01 May 2008 13:37:02 +0000

I was recently doing a project to make an add-on for Internet Explorer. How do I put it? I must say that was an extremely frustrating experience. The documentation is severely lacking, if not non-existent. One page from MSDN (which states the psarray is a BSTR is even dead wrong).

I have never been more motivated to contribute to the scene by writing my own “Internet Explorer add-on writing survival guide” sort of thing, but then I realized Pete has beat me to it by opening an entire [bho-wiki][wiki].

Nevertheless, I’m writing this article so more people can find these scarce information on IE add-on. On the other hand, here are some thoughts I had when writing the IE add-on. If you’re about to write an IE add-on, these would probably be the “survival guides” you’re using (as there aren’t many).

1. An IE add-on is a Browser Helper Object (BHO)

To save you some time searching in vain, try using BHO in your Google searches. This would give you programming-related information instead of where to download the latest IE add-on product.

2. Use C#

C++ just plain sucks, in terms of writing an IE add-on. Don’t get me wrong here, the language is marvelous, but Microsoft’s support just seems broken and unfinished. The whole Win32 hacking, COM stuffs involved when using C++ just makes your life 10 times more difficult.

The interface for C# is much more usable, and you won’t have to deal with all the bullshits when programming in the outdated (and most probably unmaintained) Win32 API.

Another major issue with C++ is Visual C++ 2008 Express. It doesn’t come with ATL, which means a ridiculous amount of grunt work dealing with pointers, releasing and stuffs (as illustrated below, as I happened to use VC++ Express). VC# doesn’t have this problem and it even has a number of libraries built-in (such as regular expressions).

Example 1: getElementById from BHO

Using C++

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

IHTMLCollection * elements;
HRESULT hr = document->get_all ( &elements );
assert ( SUCCEEDED ( hr ) );

long numElements;
hr = elements->get_length ( &numElements );
assert ( SUCCEEDED ( hr ) );

IHTMLElement * element;

for ( int i = 0; i < numElements; i++ )
{
VARIANT index;
index.vt = VT_I4;
index.intVal = i;

IDispatch * elementDispatch;

hr = elements->item ( index, index, &elementDispatch );
assert ( SUCCEEDED ( hr ) );

hr = elementDispatch->QueryInterface ( IID_IHTMLElement, (void **)&element );
assert ( SUCCEEDED ( hr ) );

elementDispatch->Release();

// After all this hard work, we have finally obtained our element!
// GetAttribute is a custom function, I didn't even bother to
// list out it's content here
if ( GetAttribute ( element, L"id" ) == id ) break;
else { element->Release(); element = NULL; }
}

elements->Release();
return element;

Using C#

1	document.getElementById(id);

Example 2: execute some Javascript

Using C++

1
2
3
4
5
6
7
8

BSTR code = SysAllocString ( L"alert ( 'Hello World' );" );
BSTR language = SysAllocString ( L"javascript" );
VARIANT result = {0};

window->execScript ( code, language, &result );

SysFreeString ( code );
SysFreeString ( language );

Using C#

1	window.execScript ( "alert ( 'Hello World' )", "javascript" );

3. Use jQuery for DOM manipulation

jQuery is a client side JavaScript library to simplify common tasks (the “write less, do more” library as they say). I found it delightfully pleasant to use. It has some powerful functions like CSS selectors that would be a pain in the ass to implement in BHO. With jQuery, you can do stuff like:

1
2
3
4
5

// Find all the <a> elements with class "bookmark" and
// target attribute "_blank" and hide
// them smoothly using a slow slide up animation

$('a.bookmark[@target="_blank"]').slideUp("slow");

To use jQuery, simply use execScript to load the jQuery file on document complete.

4. About XmlHttpRequest

Fetching external Web pages using client side JavaScript will give you a permission denied error because of the cross-domain policies of most modern browsers. XmlHttpRequest must be done in the BHO. Sven offers an example code to use IXmlHttpRequest, which is very valuable considering the lack of official documentation. Pete has rolled his own CPeteHttpRequest class using WinHttp.

(Strangely enough, both of the above are coded in C++. I have yet to come across an equally efficient way to do XmlHttpRequest in C#. Please feel free to leave a comment if you have good ideas)

one of the best programmers

kiZZ kiZZ — Wed, 02 Apr 2008 16:08:35 +0000

I just read Teach Yourself Programming in Ten Years by Peter Norvig, the director of research at Google. The paragraph quoted below was pretty gross:

One of the best programmers I ever hired had only a High School degree; he’s produced a lot of great software, has his own news group, and made enough in stock options to buy his own nightclub.