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.

This one assertion spawned an important series of comments that speak to me. We have reached a TDD gate - best-practices exist for testing relatively low-scope FSM, but at a critical mass...it's a different story. With all due respect to Craig, et al, the implication that testing a WinForm is not unit-test - but team/QA-test - is just lobbing a (very) difficult problem over the wall. This is the more common approach that we are all fighting against - write code, rely on QA to discover bugs. By pulling that software asset out of the build process (compile..., deploy, unit-test, continuous integration) - we greatly increase the risk factors during production.

I was faced with this challenge on my current project, where most system-interaction is via Flash SWiF. This relatively leading-edge approach to an RI container put added pressure on including front-end thingies in the unit-test/integration steps (of build process). It was not and many person-hours ensued reacting to integration issues that should have been caught automatically.

So what should a complete TDD framework look like? I am writing a TDD Primer starting with build framework (summarized below). If anyone wants to jump ahead and propose structure for large-scope FSM i.e. WinForm feel free.

Build

• What is a build set?
• Is revision control optional? What gets committed?
• Build Framework: Required Targets and Tasks