If you haven’t heard of test-driven development, or TDD, it’s the process of writing tests before you write your code. In this way, you are writing tests as if you are asking questions in a math textbook and your code is doing the work to solve it. It is a good practice because it ensures that code is written in a testable fashion and that you have unit test code coverage from the beginning.
However, not everyone does this. There are a lot of understandable reasons for this but it often comes down to not enough resources, whether it is developers, money, or time. Of course, a lot of the people making these decisions are not technologically up-to-date, and that’s because they weren’t hired for that, programmers were. This is a subject of another discussion altogether.
So if you happen to be a developer who’s been asked to write TDD code or you are on the business side and a team lead has mentioned implementing TDD, you should have a basic understanding of what that is. Besides the aforementioned issue with resources, here are some other reasons to consider or avoid TDD:
Pros to using test-driven development
- Code is written more function-oriented
- Changes have to be deliberately made
- Catches errors when changing code that could be overlooked
- Helps debugging/writing code
Code is written more function-oriented
Whenever we write tests, we are looking to test a specific function. If your application is really simple, which is hardly ever the case, you could test it all in one test file. But since this isn’t the reality, we often break down code into smaller functions. These are what we need to be testing.
Test-driven development forces developers to think even more function-oriented. This is good because you may find ways to re-use a function. Or you might just be simplifying an overly complex function by breaking it down into smaller ones.
Perhaps one of the largest advantages is being able to compartmentalize functionality and, therefore, features into pieces of code that could be moved around or turned on or off.
Cons to using test-driven development
- Development takes longer
- Doesn’t actually catch bugs in user interfaces/real interactions
- Can complicate code
- Can be a difficult metric to explain to clients