I’m a component guy. I like to make tools that other developers use. Classes in various languages, scripts, etc - I really like to create things that make my life as a programmer easier.

Today I was working on a new component (a windows menu class for wxWindows), and I was progressing along with the unit tests. However, I had a really hard time with the output. The particular unit test tool I use, TestSuite, is nice, lightweight, and provides detailed output by way of a standard stream.

Normally I’m using ProjectBuilder/xCode when I’m using this framework, so the output goes to the output window supplied by those environments. I was using CodeWarrior in classic today, however, and couldn’t get SOIUX (the console-like output window) to work.

I used the wxMessageBox() routine for a while, but reached its character count limits real fast. So then I dug further… The application I was testing with already had a window, so I added a static text control and a button to it. Linked the button up to trigger the tests, and the output of those tests goes to the static text control.

All well and good, except for now I had totally made a mess out of my example/testing application. Test results code mixed in with example code, mixed in with code needed by wxWindows.

So, I throw all the testing stuff into another window (this means creating a new class for it). Now I have two windows, and things are a little better.

So I move the TestWindow class off to a separate file. Then I got to thinking, “Hmm… this is nice generic class. I wish I could somehow be able to use this anywhere I want without having to modify the source code of this test harness”

C++ to the rescue. I sprinkle in a template, and in an hour or so I have a generic test harness class that can be provide a test triggering/reporting to any wxWindows application - with about 5-7 lines of work by the end user/programmer. Generic, type-safe programming.

(For those of you who care, 3 lines are for an event table, telling wxWindows to trigger a the test function of the harness when the user presses the “Test” button; 2 lines are to construct and show the window, and the other 2 are optional lines that, in my code, provide a typdef and brings the test harness window to the front.)

Display is all handled by the class, all you have to worry about is writing your tests, and adding the wee little bit of code needed to include it.

Since this is a real wxWindows window that we create, this should be portable across platforms, both code wise and workflow wise. I don’t think wxLogDebug()ing things acts the same on the different platforms wxWindows supports (plus, I think my window looks rather nice :) ).

I plan to release this WDTestHarness class to the public fairly soon (with the next week or so, maybe), under the Creative Commons Attribution License