The presentation material (slides and demo source code) of my DevCamp09 presentation are on-line now and can be downloaded from the TechTalk website here.
The downloadable material also contains the framework that can be used to write BDD-style unit tests. This framework will most probably be joined to SpecFlow, the open-source BDD tool we have just launched (hence, the new namespace, TechTalk.SpecFlow.UnitTesting).
Session Abstract
Developer life was good in the golden age of the waterfall: big upfront designs left no surprises for later implementation, code documentation was a piece of cake as nobody else read it anyway, and testing was something developers just heard of remotely through a department called “QA”.
But things have changed for the worse with the rise of agile methodologies: designs are ruined by requirements coming in weekly and code that was already working perfectly suddenly breaks. Now, business wants to collaborate directly and is interested in details of the implementation, meaning that documentation can no longer be kept on the back burner. And QA is asking for a high coverage of unit tests out of the blue, causing big overheads to write and maintain them with all these ongoing changes.
However, a lot of concepts have been introduced that promise to ease the pain: IoC helps us reduce dependencies in the code, BDD helps us focus on the next functionality to deliver, TDD helps us structure code for testability and Fluent Interfaces are a way of building DSLs that help us communicate with business.
This talk will show how we put these concepts into practice in a project that followed an agile methodology. We’ll show how IoC helped us stay flexible, and how we structured our unit tests in a way that described the expected behavior and could also be understood by business. The source code of the supporting infrastructure we built will be made available to you after the talk as a download.
Screenshots from the demo
Execution result of a very simple BDD-style unit test
…and the unit test itself
Execution result of a more complex BDD-style unit test
…the unit test…
…and finally the implemented code