Unit Testing Training
Unit Testing has been one of the dearest technical subjects for me in the past years. A great influencer was a TDD Workshop lead by J. B. Rainsberger to which I was lucky enough to attend, somewhere in 2010. It was a very good fit with the moment of my career. I was starting to realize that we are quite far in the way we are developing software from the principles and disciplines advocated by different industry leaders. I was looking for concrete methods to improve the way me and my team colleagues w software.
JB not only that has taught us what Unit Testing and TDD are, but he also demonstrated a powerful technique: getting to a modular design driven by unit tests and by some simple rules. He showed how to achieve a design that is inexpensive to change, by minimizing the accidental complexity. This has made me to see in unit testing one of the most efficient tools for assuring a sustainable quality level of the code in the projects I was involved in. It motivated me to teach others to write Unit Tests that benefit them in the quality level of their production code.
I wanted that the next projects I will start to work on to begin with a training on unit testing. I wanted that the entire team writes and cares about unit testing in a consistent manner. This is how my Unit Testing training was born. I have initially developed it for a newly created team that was starting a challenging project on a tight schedule. I knew from the start that it will not be possible for the very few seniors to review enough and do enough pair-programming with everyone, so we can have a sustainable quality level in our code. We needed a flexible design which could accommodate the volatile requirements we were supposed to deal with in a predictable way and at reasonable costs. I thought that if everyone would cover with good written unit tests their code, than we would end up with a design that is good enough. Maybe not the best one, but good enough. And, it worked! Even if we were on a tight schedule, the initial investment in learning and writing unit testing, paid off in the end.
Since then I have redone the training many times for different teams in ISDC and for some of their clients. We have a seen many benefits not only at the project startup, but also for ongoing projects with existent teams. It is always about reading and changing code, rather than writing code. Unit testing, if done the right way, can significantly increase the efficiency and predictability of the changes we do in code.
Another motivation to build this training was to share with others my experiences of learning unit testing. For many teams it is very important to start on the right track with unit testing. When unit testing is done incorrectly it can cause schedules to slip, waste of time, and it can low motivation, and code quality. It is a double-edge sword, which many teams learn to master the hard way. One of the lessons I’ve learned the hard way was: “Never treat your unit tests as second class citizens”. It was in one of the first projects I was learning unit testing on. We’ve ended up after a few weeks with a tests suite, which was breaking at any changes we were doing to the production code. We couldn’t refactor or redesign the production code, because the tests would break. It wasn’t because of poor design of the production code side, it was because of the poor quality of our unit testing code. We have created a too strong coupling in test code, which turned out hurting in the production code as well. I and my team colleague ended up in drawing sticks on who is going to spend the weekend to fix the tests. I wouldn’t want anyone to repeat this painful experience.
In the past few weeks I have taken the time to review, refresh, enrich and restructure the entire training material of my course. I have added the topics and examples for which, until now, I never had the time to detail them as I wanted.
At start, the content was largely built based on Roy Osherove’s The Art of Unit Testing book. Now I have enriched it with new elements from the books and articles of Kent Beck or Martin Fowler and others. I have also taken to opportunity to reshape the training with my experiences from last few years and to add the new things I have learned from pairing with different people at code-retreats or on other occasions.
The training focuses on two main aspects: maintainability of the tests and the benefits on the quality of the production code. The tests code may be a significant amount from all the lines of code forming a project. However, even if it is big in size it is important that it does not increase the complexity, so it has low maintainability costs. The greatest benefit I see from doing Good Unit Tests is in the design of the production code. By learning a few aspects about how to write your tests you can exercise a positive pressure on your production code leading it towards a better design.
UPDATE: I have published a presentation page with the full format of the entire course here.