TDD for Managers

We all know that Test driven development, TDD is much better than test last approach, in test last we write unit tests after writing required code. But somehow the industry still doesn’t reflect this learning in practice. According to various surveys, the amount of developers who were aware of TDD and its benefits were huge but those who were actually practicing it, in its fullest of its spirit were limited. The main culprit is that TDD is difficult to master and given the tight project deadlines one would need great motivation to learn, practice and master it by themselves. I do believe that considering the amount of benefits TDD can offer it is definitely worth spending that extra time and effort to master it. Here “time and effort” directly translate towards extra cost and such budgeting decisions are made by the so called manager class and hence this blog is dedicated to them.

One more point to be understood is that we are discussing about “Test Driven Development” not just “Test first approach”, in Test Driven Development we test drive design along with implementation and we are strict with the red, green & refactor cycle. Hence “Test Driven Development” is always “Test first approach” ,the converse need not be true.

Below I have listed down 15 different attributes to compare and contrast TDD with test last approach. We should understand that in both these approaches we get the benefit of test automation. I hope this article would help managers & leadership to make informed decisions to do whatever it takes to inspire and coach development teams to embrace TDD into their work culture.

Better design

TDD helps in getting our production code less coupled, as that is the only way we can easily test each component. When we are in the TDD mode we think of two separate system’s to be built. One the system than needs to solve our problem and second, the system that can test the system that we are building. As we always start with the test the easiest approach to build a system that can be easily tested is to ensure that it has low coupling. Having coupling under our control is one of the major design goals, in fact one of the most important from software maintainability point of view. In test last approach you don’t have this benefit. In order to get a good design one will have to intentionally put some thought and effort.

Refactoring

If you are in the TDD mode it helps you refactor the code even during development and also after development. This is because even during the development we have a safety net cover of tests. In case of test last strategy, refactoring the code base after development could be fine but refactoring the code base during development of a feature could be challenging as we don't have the luxury of having a safety net of tests. Hence TDD scores above test last approach

Coverage

TDD by its nature of its disciplined approach ensures that we have 100 % coverage. Whereas in test first there could be a possibility that the developer could unintentionally miss out certain scenarios to test. We might need tools to verify that. I am not a fan of coverage , its just a parameter to compare.

Drives development

Programming by intention is what we always practice during test driven development and this thought process always helps us drive the development process.

Development time

It is a myth that during test driven development one would take more time, this is because a developer spends more time thinking what and how to write, than writing code. TDD helps the developer in this thought process. Hence the overall development time typically reduces in case of seasoned TDD practitioners. In case of test last approach the amount of time taken to write unit test after the development is always an overhead.

Fun

Test driven development is addictive and more fun, seasoned professionals also follow the Ping Pong style of pairing which makes it more entertaining. In case of test last approach the developer doesn't feel this fun element when writing unit test. The fact is that most developers don’t enjoy writing unit test.

Coder’s blocks

Coder’s block could last for hours to days and sometimes even weeks. In TDD we don’t think too much and we are focused on making a tiny progress hence the chances that we end up in a state of coders block is very less . Trying out TDD if you’re suffering from Coder’s block could even help you get on track.

Feels happier

As a developer every time when we see the green colour we feel happier. Each time when the colour changes from red to green we have accomplished something by adding value to the system, this thought process keeps us motivated and makes us happy. Whereas writing unit testis after development is always a boring activity. 

Easier to test / testability

In TDD as we think test first, the production code will be less coupled and hence easier to test. This is always not the case for test last approach. There could be that one bad class with high coupling that could be difficult to test.

Instant feedback

TDD scores as developers get instant feedback during development and not after development.

Aids in emergent design

            In TDD we embrace programming by intention and aggressive refactoring which will help the design evolve. 

Less Time spent debugging

TDD practitioners typically forget the hot keys of their favorite debugger as the amount of time they spend debugging is very less. They are always a minute away from shippable code. During development even when the color is red a couple of Control + Z can get them back to the green state. I.e. a state where all the test have passed and ready to be shipped.

No separate defect fixing phase

In case of test last approach after writing the tests the developer will have to check by running the test suite to ensure that we have the expected behaviour. In case defects was found the developer will have to spend time fixing it. Where as in TDD this process is not a separate step as it’s dissolved in the development process itself.  It’s been observed that the time taken to fix a bug after development is more than time taken during development.

Quality of test

Since following TDD ensures that the production code is more testable than test first approach, the quality of test will also be better. Please note coverage and quality of test are two different attributes.

When we have classes that are highly coupled then it could be difficult to test the classes for different states changes and interactions. This would mean that the quality of test will come down.

Easy to master

Test-driven development is a concept which can easily be understood but could be extremely difficult to master. This would mean that the developer needs to spend substantial amount of time practicing this technique in order to master it.

 Conclusion

TDD definitely over shines test last approach in many areas. TDD is also difficult to master. Considering the amount of benefits TDD can offer it is worth spending the time and effort to master the same. I also firmly believe that TDD is a skill that should be taught to students starting from schools and colleges.

I would like my fellow colleagues, practitioners and coaches to add upon if I had missed any specific attribute also let me know your thoughts and feedback.