Where do we start to pay off technical debt?
One of the problems is the time it takes to release functionality to customers. With each change we need to re-test the product. The QA people are overburdened with manual regression tests.
There’s also the problem of how to redesign some of the code base. We want some sort of check that makes sure that released code is of a consistent quality.
My experience lies in Automated Testing. I first wrote a unit test around 2001 when Extreme Programming was the new thing. Since then, I’ve discovered many ways of doing things. Some good, some not so good.
Initially I saw automated testing as something you did purely for regression tests. I would jump right in and start making changes to code. Then I’d scratch my head and wonder about all the database setup and context I would need in order to validate my code. It became a maintenance headache.
A common question I came up against was what is the value of something that doesn’t manually test software end to end? I was told the only way a test was meaningful was if it went through the UI. But I’d worked on software that was tested through screens before. The testing tools were based on the idea of automating the pointing and clicking on the screen, then verifying text on the screen. These tests seemed to always fail even though nothing had changed. They were very brittle.
Then came the concept of TDD and unit testing.
Test Driven Development
TDD is a development methodology that aims to catch problems early on.
It is best to catch problems early. It is far cheaper, in terms of time and effort, to fix a problem in development than after it has been released to a customer.
There are many great examples of this in software and also in areas such as car manufacturing, the building industry and space missions.
In TDD, developers write small tests to specify what a unit of code should do. Then they implement the code to satisfy the requirement. The code is tidied up, as they go, without breaking existing functionality.
Instead of trying to do a big design up front, it works iteratively, evolving the code to solve a problem bit-by-bit. That is why it works best with iterative methodolgies such as Agile.
It provides the following benefits:
- a set of tests that exercise the code and tell us early if something breaks
- better quality code
- more maintainable.
- focussed on a single defined problem
- modules are inherently less tied together
- documented functionality that is a true representation of what the code does
- promotes group ownership – the team collectively own the code and verify it as part of a build
It is important to note, it does not replace good software architecture and domain knowledge.
On its own, TDD will change the way we develop but it will not solve every bug. It also does not guarantee we deliver the right thing. It should be used in conjunction with other good practises.
A common question is how much longer will it take to do TDD? The answer is it depends. There’s a good post on @mikehadlows’s website addressing this. I would say to start with it can take some getting used to. It may take twice as long depending on the problem and experience of the team. Overall it should make things easier – especially as the post development testing cycle tends to add on a lot of release time and is rarely factored into the coding time.
For more information and some real world case studies see: