Friday - TDD and Interface-based Programming

DVM303 - Understanding Test Driven Development Speaker: Roy Osherove This is my 3rd session with Roy following from Designing for Testability and Future of Unit-Testing. TDD helps with

• trusting your tests
• designing the app (because it forces you to take the point of view of the client)
• implementing stuff that works partially as opposed to not at all
• code quality
• documenting the code
• reducing integration testing time, reducing number of bugs in production

How to write a unit test with TDD?

• add attribute [Test] to methods, [TestFixture] to classs
• naming: tests must have a good name to document their intention: method + scenario + expected behaviour.

Content of the test:

1. arrange (instatiate objects)
2. act (call the method under test) ,
3. assert (check the expected result)

Writing process That's the interesting bit, the part that's totally couter-intuitive and requires a good dose of self-discipline.

1. Make it Fail: write a test that fails because the method is not doing what's expected. Purpose: test your test
2. Make it work: with minimum code, make the test pass by writing anything even if it's stupid as long as it doesn't break any other test.
3. Make it better: refactor but do not add functionality and make sure the test still passes.
4. Want to add more functionality? Ok but write another test first.

Tools:

• use Testdriven to run test by right-clicking method in the middle of the method. Apparently TestDriven allows you to run a test even if you don't have a fully working executable.
• If you use VSTS, use the built-in MSTest because it brings a lot of integration benefits. It runs slower though. Usually unit-tests are kept in a separate VS project.

Tip from Roy: it's a bit of a culture change so implement it incrementally and don't mention it by name to avoid scaring people off! ARC213 Intentions & Interfaces - Making Patterns Concrete Speaker: Udi Dahan Very sarcastic talk by Udi, making fun of the abuses of the visitor and strategy patterns. "Make your roles explicit" Instead of overriding virtual methods, use generic interfaces. You then retrieve concrete objects for those interfaces from service locators. In the end he was recommending Inversion of Control containers as Roy did in his testability session but with a different approach. Roy's emphasis was on writing code so that unit-tests stick to PC-COF while Udi's angle was on making it easy to change code in large projects. Slides.