One of our internal projects at Y Soft R&D carried out by the Lead Developers is to prepare and maintain internal teaching materials. We have only recently started with the project and our first goal is to prepare trainings and drills for the baseline level to establish the basic skills each and every developer at Y Soft needs to know. Parts of it are also relevant for other colleagues, like Solution Architects, due to them writing and testing customizations.
Our baseline level is modeled around 4 Rules of Simple Design and we are now working on the first part, which is covering unit testing. We spent a whole day to prepare simple rules to help developers write good unit tests, defining what we call Unit Test Patterns.
There are four patterns we have defined:
- Referentially Transparent Contract
- Non-Referentially Transparent Contract
- State Inspection
- Side Effects Inspection
The first two are modeled after Classic TDD while the latter two are modeled after London school of TDD (What’s the difference?).
We are now preparing the coursework, guidelines and exercises to stick to the following outline.
- Unit Testing Trivia. The AAA / GWT principle.
- Using frameworks and tools to write / run unit tests in Java and C#.
- Unit Test Patterns. The Decision Flow or How do I know which pattern to use?
- Writing Tests using the RT Contract pattern
- Writing Tests using the non-RT Contract pattern
- Writing Tests using the State Inspection Pattern
- Writing Tests using the Side Effects Inspection Pattern
We want to produce internal web casts for the first three and Koans like exercises for number 4 – 7. Essentially providing contracts to write tests to and evaluating the tests by executing them on several purposedly flawed implementations.
The purpose of this is not to reinvent the wheel, but provide an easy to use, simple framework to help design and write unit tests.