For about eighteen months I have chewed on an idea for something I call Distributed Continuous Integration Build. The idea has had to stew behind other priorities - like the birth of my fourth child.

The timing seems right to demonstrate a pattern for testing asynchronous processing. This follows up on Steve's assertion: Don't make assumptions, write the test.

Most product architects using NAnt have never delved into its precursor, Ant. The converse is true as well. After spending some time researching Ant I have a few thoughts (gasp):

• Ant and NAnt share 99% of core design principles.
• It is critical to understand the 1% in which they differ.
• You can design equivalent steps in each.
• Ant is a more feature-rich tool (filter, filtersets, scoped properties).
• Neither tool protects you from poor organization and/or componentization.

I have mentioned the PluralSight guys from time to time - they sort of amaze me. Dads all of them, yet somehow they seem consistently on fire. Andera's recent TDD musings are a must-read if you are ready to push the envelope of where TDD can be use(d)(ful). And that is where I am. For four years I have used an agile development mindset (methodology if I was the architect) - committed to the basic precepts of assert-build-integration.

But sometimes, what you're testing is a lot more complicated, like a WinForms control. There, the thing we have to simulate is the windowing system itself, since that's really the client of my control: Windows sends events to my control, and my control sends painting commands back.

No, this is not a political column, rather another post on the topic of TDD.

A friend of mine and fellow architect wrote: “What about the loss of objectivity when a developer specifies his own test cases? It must require a conscientious mindset.” What about it? Fortunately, the blog format doesn’t require one to give answers rather one can just post opinions. I am debating this issue myself. How can we ask a developer to provide an all-inclusive set of tests even in the purely hypothetical case of a complete spec?

First of all, if we are following the mantra of TDD – add a test, get it to fail, and write code to pass the test – the initial set will not be complete. We then iterate in small steps to eventually achieve a sufficient level of confidence that the solution just meets the acceptance criteria set forth by the client. Thus, we asymptotically approach the perfect test set reaching it after an infinitesimal long time period or as soon as the system is decommissioned.

I’m here in the trenches fighting for Test Driven Development (TDD), while Rjae is providing us with insight into up and coming technologies. A contradiction? Percs is not the place for discussing issues at the ground level of technical innovation?

We don’t think so! After all, if web services will be our future for defining a contract both metaphorically and soon probably legally speaking, we need a better way to both enforce and verify its implementation and fulfillment.

So start with an interface definition, which can be a wsdl, business spec, interface, or whatever else you have (even a verbal from your client will do) and write a test. Make the test work and then write your implementation, and you will be able to sleep at night while your service services clients in an 24x7 global environment.

Craig Andera - one of the PluralSight dudes - writes about his experience using TDD with FlexWikiPad.

But regardless, it's been an interesting experience writing a GUI app, which is not something I usually do. It's been particularly interesting developing it with a TDD approach, as GUIs present some unique challenges.

I hope he blogs about it: the special approach hurdles developers navigate using TDD for GUI components.