Tuesday - Designing for Testability

ARC307 - Designing for Testability: Bridging the Gap between Design and Testing in Object-Oriented Software Speaker: Roy Osherove Probably the most inspiring session so far. It struck a chord because I recently gave some serious thought to coding unit-tests and using TDD. What has been holding me back so far is that most unit-testing frameworks seem to be targeting the .NET framework as opposed to native C++. For each piece of coded logic says Roy Osherove you should follow the PC-COF rules:

• Partial runs possible
• No need for Configuration
• Consistent pass/fail
• Order does not matter
• Tests must be Fast

Dependencies between objects should be based on interfaces (to enable creation of mock objects), which then raises the problem of dependency injection: how and when do you pass a concrete object A to an object B that expects interface A? You can do injection in various ways:

• Constructor (forces you to pass a concrete object)
• Property (passing the concrete object is optional)
• Factory (passing the concreate object is done as part of a factory method)

It can become very clunky to do code injections for all objects unless you use inversion of control containers. Those containers hold associations between abstract interfaces and concrete objects. Inversion of control frameworks:

• Spring.net (I met one of the authors of Spring.net at TechEd Orlando)
• Castle.Windsor
• StructureMap

Unit-testing tools:

• MSTest (the one integrated in Visual Studio Team System)
• Nunit
• TestDriven.NET
• Typemock isolator

Slides