Test Driven Development is Hard

Really hard.

Sure, writing a contrived test for a simple function is pretty straight forward. There are many frameworks that developers use, and some will even form the test stubs for you. Having the discipline to always write tests is a challenge. Writing test first for weakly defined requirements is difficult. Retrofitting large and complex legacy code bases get hard – and costly.

Test first promotes modularity, clear requirements and acceptance criteria. It encourages thoughtful domain modelling and ensures code works as intended. But what if you don’t have clear requirements, if you inherit a mud ball of legacy code, the language is new and the budget tight, where do you start. How do you decide where to focus your efforts, what parts of the code to test and what to refactor?

The first thing is to commit to writing unit tests. You then need buy in from stakeholders – users, analysts, managers and fellow developers. This is an important and valuable exercise. The stakeholders need to know what’s in it for them. This can help get a team focused and all pulling in the same direction. So, what are the advantages of test driven development for project stakeholders.

Users: Test Driven Development encourages users to think about their business requirement in clear terms. This results in quality applications that satisfy user requirements with less errors.

Analysts: Encourages requirement gathering that is clear, organised, atomic and written with well defined acceptance criteria.

Managers: Higher quality applications with less errors. Lower lifetime cost of software by lower cost maintenance.

Developers: Can rest easy knowing their code works as intended. That requirements are clear and changes are nothing to fear.

Once the testing framework has been established, in the case of legacy code you might find that that much of the applications features cannot be tested. The logic is split between layers and classes, there are branches that cross multiple classes and layers. It is then time to refactor the code base. Check out Martin Fowlers book Refactoring.

New features should have tests written first. This should be manageable as the user requirements are now well defined and thought out with clear acceptance criteria. Happy managers that see the value in unit tests and developers who can make changes to the code with confidence. Developing software is a team effort, and test driven development can help focus a team. The best time to start test driven development is your next line of code.

One thought on “Test Driven Development is Hard

  1. Hi Darryl, nice article!

    On additional benefit for my is being faster when creating new functionality. This might seem unlikely, but imagine a huge web application with complicated workflow where you have to click through quite a few pages until you reach the desired functionality. Then you have to enter data, hit some button and check the result. Having a suitable unit test I might just fire up the unit test runner and can verify the result, no clicking around involved.

    Like

Leave a reply to Bob Cancel reply