In Vivo Test Pattern

Problem

You need to use TestDrivenDevelopment to create an application on a platform like MicrosoftFoundationClasses, architected for some form of VendorLockIn. The platform controls your main() and your View message pump.

(To be fair, sometimes the platform is just big and slow, and VendorLockIn is not to blame!)

To achieve TestIsolation, you might need to create everything in each setup() and break it all down in each teardown(). This can be slow, or even impossible, if the platform constrains how you can call its parts.

Solution

Write the default application skeleton, in all its hairy glory. Then - maybe even as low in the call tree as your early View events - call into your test runner, and pass in a reference to your environment.

Each test case expects a fully-formed environment, with all its elements, possibly even including a main window.

Benefits

TDD is better than debugging, no matter how sick your TDD rig must be!!!

Drawbacks

For each bug, and each unexpected test failure, you must consider and work around TestIsolation. Your teardown() method might, for example, whack every object in your object model that's further down the object tree from your basic objects.

Fixing the Drawbacks

Run the tests as often as possible, constantly refactor them for cleanness, and if tests fail unexpectedly revert the code until they pass.

See WorkingEffectivelyWithLegacyCode...