I have just published my specs of the Tennis Kata at github. I am using our inhouse infrastructure for unit testing. This means separating the Act from the Assert by having two different classes. We also use a inheritance in a very simple given-then-tree. This let us explore different permutations of method calls, and after each method call we can do assertions. It is a kind of storytelling, but without all the noise that acceptance testing frameworks usually have. We start with a Construct_Act that creates the class under test. Then creating a When_Constructed class that inherits from the Act – this will contain the asserts. Further on we make a PlayerOneWinBall_Act that inherits from Construct_Act. Then creating a When_PlayerOneWinBall : PlayerOneWinBall_Act class that observes and asserts. This gives a nice given-then-tree with namespaces as the Given-statement. It certainly is a lot of classes, but each class is dead simple and we are not violating Single Responsibility Principle for the test class itself. Each ‘Act’ and ‘When’ class has only one context with high cohesion. Another pro is that we only construct the class under test once – so changing the constructor does not lead to massive refactor in test code. For readability I have also created some empty act classes (e.g. At15_0_Act) . We really don’t need them, but it is easier to read ‘class PlayerTwoWinBall_Act : At15_0_Act’ than ‘class PlayerTwoWinBall_Act : PlayerOneWinBall_Act’.
Because stupid wordpress doesn’t allow plugins, I published a typical Act-class at pastie.org.
The given-then-tree, after all it’s all about state transitions: