Test-Last Development (TLD) vs Test Driven Development (TDD)
December 10, 2021
STORY 1: Test-Last Development (TLD)
Month 1-3: “We’re just getting started, this is just a simple CRUD application, we’ll skip automated testing because will slow us down, we need to code features as fast as possible”. Demos pass really well, clients are happy.
Month 3-6: Most of the sprint is spent during bug fixes, feature delivery has really dropped. In fact, most time goes into debugging and trying to not break the existing system. Clients aren’t so happy, they say the development team isn’t delivering enough and that the software is really buggy. “We wish we had automated tests, the manual debugging and manual testing has now become so time-consuming and every sprint demo and production release is stressful. Let’s start doing some automated tests now”.
Month 6+: Coding is done during the sprint, and then automated tests are left to be done “later, when there’s time”. But the time never comes along. Feature delivery drops further, management decides to add additional developers to the project. This causes even a further drop in delivery and even more regression bugs. “Well, looks like automated tests aren’t possible, they take too much time, this is just the way it is in IT, there’s nothing we can do about it”.
STORY 2: Test Driven Development (TDD)
Month 1-3: “We need to build in quality right from the start”. The team analyzes user stories and writes automated tests derived from the acceptance criteria. “Done” means automated tests pass.
Month 3-6: Client has lots of ideas, changes come in. Changes are welcomed by the team – developers write automated tests for the change, then implement, check other existing tests pass. The majority of the sprint is spent doing feature development, and very few bugs. Team velocity is maintained. Sprint demos and releases are painless.
Month 6+: Management expands the team with new developers. The new developers write tests for features and changes they need to implement. They also run through the existing test suite to make sure they didn’t break any existing functionality. Team velocity stays high, and the team is able to scale.
