The Agile Tribe

The Evolution of Test Driven Developers

on June 9, 2011
Author: Peter Sellars (Reprinted with thanks to Peter)


Test Driven Development (TDD) since its rediscovery by Kent Beck in the early noughties has led to an evolution in the information technology developers of our species. So where on the test driven developer evolutionary tree do you or your developer kind sit?

This is a light hearted look, with some serious undertones, at the evolutionary state of Test Driven Developers. I hope you enjoy your journey of discovery…

Homo Habilis

Homo Habilis

Sitting at the bottom of the Test Driven Developer evolutionary tree this member of the species is not really a Test Driven Developer at all!

This member sees no need to write any tests, holding the belief that they write defect free code first time all the time. He makes extensive use of copy and paste techniques, deeply nested conditional statements and has no understanding of design patterns. They add to the technical debt of the project constantly as a result.

They can often be seen up to their necks in a debugging session trying to fix production issues. Issues introduced by other members of the species according to the Homo Habilis team member!

Some members of the tribe known as ‘management’ are impressed by this members code output blindly ignoring the number of defects and regression issues introduced by his work. They have been the cause of revenue losses totally millions of dollars. Far from being extinct, this species is a menace to the development society.

If you encounter one of his kind please remove their head from their ass and teach them to read before getting them to read this blog post ‘TDD for Dummies’. 




The lowest member of the evolutionary tree that attempts to write tests. They do not really understand why they are writing these tests and do not understand the benefits testing provides. They had seen a member of the Tester species write something called a test and due to their nature of imitation tried to do the same.

Their tests are written after the code and  follow only happy paths through the code (the Tester they had witnessed was low in the Tester species evolutionary tree). This member copies others and has limited capacity for improvement. There poor development practices and inability to understand design patterns adds to project technical debt, even though some of the tests they add do help manage a little of this debt.

This member is usually covered in debugger fall out due to the limited tests they have been able to construct. The minimal coverage and paths their tests cover do lead to hours of howling and teeth-baring production debugging sessions. Often code added or fixed by this member leads to regressive defects.

They are unable to comprehend how these defects get into the codebase, as there limited brain capacity leads them to believe that their tests provide enough coverage to minimize risks. Time and time again this has proven not to be the case, but this member struggles to understand how!

Tribe ‘management’ see this member carrying out testing and consider testing to be a waste of time – due to the large number of defects still occuring. These ‘management’ members of the tribe do not see the quality of their testing as the issue, not the testing itself. This makes it extremely hard for more advanced members of the species to push for an increased testing focus.

This legacy of testing being a time-wasting exercise delayed the evolution of the Test Drviven Developer for some time. Thankfully some forward thinking members of the tribe ‘management’ team realised the errors of their way and led the acceptance of more evolved Test Driven Developers.

If you encounter one these members help them slowly comprehend development best practices, and point them in the direction of introductions to Test Driven Development such as Kent Beck’s Test Driven Development: By Example to assist them on their evolutionary journey. Then hope for the best, based on their limited learning capacity.



This member of the species is the earliest evolution of the modern test driven devloper. This member sees tests as a way to exercise the code they have written. They write tests to check there code works as they intended it, a major shift in the evolutionary chain.

They write tests after the code and understand that testing their code, even if it is pure genius, will lead to less defects reaching production. They are capable of recognizing the need to test more than just happy cases too, including alternative cases to improve code coverage. Technical debt is more than just two words to this member, there focus on coverage helping add confidence in the technical quality of their code.

Whilst they lack understanding of development practices that could lead to more testable code, this member has also not connected the use of testing to drive design yet.

The test-after approach employed by this member does provide limited support for refactoring. Refactoring to this member involves changing code, not improving the code design. As a result refactoring often leads to numerous test cases being updated. This limits the value this member sees and gains from their refactoring methods.

The testing this member carries out does tend to result in less defects released into the wild. Many defects are found during local development supported by their tests and less regressions occur due to a vision of automating tests much like they had been doing with their builds for many years. This member rarely ventures into debugger territory prefering the safety of their test cases.

This member of the species is the leading member of the species population wise. For all their evolutionary advances such as test coverage, defect minimisation and understanding of technical debt, this member has missed the attention to business value that more evolved members have grasped. Their technical focus often leads to over-engineered solutions and unneccessary frameworks.

Tribe ‘management’ appreciate the reduced number of defects this member releases to production. A number of visionary managers are searching for more. These visionaries challenge members to visualize the business value they provide. This member’s days as the most populous member of the species are numbered with the introduction and encouragement of more agile testing practices.

If you encounter any of the most populous members of the Test Driven Developer species inform him that TDD is more than a testing exercise, it has just as much to do with emergent design and get them to start reading about Test-Driven Design  in Neal Ford’s developerworks article from the Evolutionary Architecture and emergent design: Test-Driven Design, Part 1.




This member of the species is the first to exhibit an understanding of the design aspect of Test Driven Development (TDD). Using test first development this member has come to understand that writing the tests first helps drive the design of their code.

They were the first members of the species to benefit from the leaner code base and improved business focus test-first provided. Technical debt is well understood by this evolutionary advanced member of the species, and coverage is just one of the many code inspections undertaken during development.

Refactoring to these members is more about improving design than changing code. They benefit from the capability to make more aggressive refactorings as a result of this understanding of refactoring. Code produced also tends to exhibit better design concepts and patterns as well as being more focused and leaner in format. Understanding of automated test techniques such as regression testing enables them to support purer design refactoring.

Another evolutionary shift achieved by this member is the behavioural nature of their testing. Behaviour Driven Development focuses on a Given-When-Then structure for test cases that this member has mastered. Behaviour testing focuses on what happens rather than technical mechanics enabling improved business focus. BDD enables teams to measure how much of the business functionality has been met.

These members rarely need to enter the evil lair of the debugger when fixing defects. They add tests that exhibit the defect failure and then fix the defect. They believe in the power of regression tests to prevent defects reoccurring and are very succesful in this area.

Tribe ‘management’ are impressed by the ability to measure the business functionality coverage, and the business customers appreciate the added value and confidence tested behaviour provides them. This member of the species is highly sought after. Their numbers are increasing in the wild and the development family is all the better for that.
If you meet one of their increasing number out in the wild let them know that ATDD (Acceptance Test Driven Development) adds even more business value. Get them to order and digest the currently MEAP Specification By Example by Gojko Adzic.

TDD Guru
This member of the species has only recently been discovered. There numbers are minimal at the present time, and these members will be at a premium real soon.  Not only do these members use TDD as a design discipline and test exercise they have also quite amazingly been able to attach it to ongoing business value. They have been able to show the business value provided throughout the development cycle. This member uses the ultimate weapon in Test Driven Development, the latest evolution in TDD tools, the living document.

This living document uses specifications by example to exercise business facing tests with realistic scenarios provided collaboratively by the customer and development team. These bussiness tests build on the fundamental foundation of unit tests, these members recognise that test typers are not effective in isolation.

Adding new business value for these members involves writing business facing tests, backed by technical unit tests. This methodology they have evolved encourages greater focus on providing business value as well as resulting in leaner code creation. These members are close to genius in capability.

This living document forms part of an Acceptance Test Driven Development (ATDD) methodology evolution this member promotes and encourages. The ATDD methodology builds on the foundations of Test Driven Development (TDD) to deliver code testing business specifications. These specifications exist in the living document recreated each time a build occurs, which means that this document is constantly relevant.

The living document is a live requirements document. Each version of the application has its own version of the requirements. Each version can be tested against it relevant requirements. This giant step in the evolution of TDD should not be underestimated. These members almost always pick up defect prior to release, through the use of specifications by example, showcases and user tests. They recognise the value of collaboration during all aspects of the development process.

Defects that do slip through are quickly fixed and released through the use of continuous integration, regression tests and customer confidence. This member has mastered the skills that minimise the time from concept to release of features or defect fixes.

Debug is a dirty word to this member of the species. They feel violated when they need to use a debugger to fix issues – prefering the cleaner environment of the test case creation. They also utilise code inspection, coverage and regression tests to help them fix defects and maintain a managable level of technical debt.

If you come across this member, hire them quickly and monitor their evolution – what will be the next evolution in Test Driven Development?

Where do you sit on the evolutionary tree?
So where in the evolutionary tree do you or your developers sit? I have included a poll on my blog site  to create a census of the current state of Test Driven Developers in the industry.  It would be great if you could spare 2 seconds to vote, and even better if you could take the time to comment on my interpretation of Test Driven Developers evolution and add your thoughts and experiences of Test Driven Developers. 

Where to find more reference material about TDD? (Editor Note)

The Agile Academy has a series of open source Agile in Practice Help Sheets and Videos (just click on the link) on our Knowledge Hub which includes TDD and Automated Testing.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s