Test Driven Development (TDD): The Advantages and Disadvantages
During my time as a software developer I have worked in contexts that use Test Driven Development (TDD). It is one thing to enjoy it (I did), it is another thing to be positively encouraged to engage in a process that increases the quality and maintainability of your work.
If you are looking at companies you might work for or with, their software development process is one indicator of how well they implement methodologies that makes their life easier. One red light for an interviewee is when a question about TDD is asked, but the interviewer has only a shaky idea of what that means in practice.
The TDD process involves writing a Unit Test before code is written. For the developer this means you must know the behaviour of the code before any particular algorithm is written to solve a problem.
Part of the value of the TDD process is that the specification for the code must be known before work on that code is started.
Once the test is written, a cycle is entered into to create production-ready code that follows the process flow in the following diagram:
Note that the TDD process does not stop you refactoring code and maximising the efficiency of code that will go into production. It also does not preclude the usual code review process, even through arguably you are reviewing your own code as you go (with a good quality test making it clear whether or not your code is of suitable quality).
Advantages of TDD
The requirement of writing tests before code, means the specification for any particular unit needs to be fixed before the code is written. Therefore the requirements of the software as a whole will be confirmed as the software is developed.
Testing and refactoring are baked into the process, which by definition encourages rigor in the production of quality code.
Unit testing itself encourages modularity in a codebase, and TDD helps with producing well-tested code that has a high percentage of test coverage.
The TDD process should save time in maintenance, as defects should be easy to find and are found early in the development process (a fail fast method of production).
When developers are involved in testing rather than just handing off their work to a testing black box, they are more likely to be engaged in the process and take testing far more seriously than perhaps they otherwise would.
Disadvantages of TDD
Ideally a whole company or organisation needs to support the implementation of TDD in order for it to succeed. Writing tests before writing code means that we need to know the requirements of the software and the specification of the code before starting to code the solution.
Ask yourself this:
Is the business set up for TDD?
TDD can (and certainly in the early stages of a software project it does) take longer to code and some of the advantages are only seen in the maintenance portion of the software development process. Some managers want to see code written now, and take the later consequences of poor development processes when (and if) they come.
All code should be modular, which makes it easier to implement testable code. However, we have all worked on software projects that are not well implemented for one reason or another, and we may need to join a particular project that has been through some shaky development practices as it nears completion.
We might be led to ask ourselves:
How can we easily implement TDD in a non-modular codebase?
I’ve written several articles on mocking and dependency injection, as this is something that junior developers can struggle with. Developing skills around stubbing and mocking can take time, and is this something that the team is aware of and prepared for?
Which brings us to an important point. Is everyone in the organisation on board? Are there developers who think they write perfect code (I think I’ve worked with this developer before; their code is awful) who refuse to implement the TDD process? How can staff be engaged, and encouraged to point in the same direction in order to produce great work?
The advantages and disadvantages of TDD actually look fairly balanced. Look more deeply, however, and you see the balance is in the quality of the software and a team investing in this early in the development of software rather than leaving maintenance to the end of a rather long cycle.
If you can develop TDD within an organisation, if you have staff that are capable it seems like a common “no brainer”. This is not to say that it’s right for every organisation (it isn’t), but you need to make your own choices with the knowledge of your organisation and programming context.
The Twitter contact:
Any questions? You can get in touch with me HERE