In the world of software development, Test Driven Development (TDD) is a well-known and commonly used development methodology. TDD starts with the test code and then followed by the actual software code.
You might be thinking, “Why would you want to write test cases before the actual code? “. Or maybe, “It seems like a big waste of time.” In this post, I am going to talk about TDD and hopefully, it will address some of the questions you may have about it.
What is Test Driven Development
Test-driven development starts with developing the test for each feature. The test will fail initially because there is no actual source code for the features. Then the development team develops the code to pass a test and refactor the code as they expand the code to pass another test. At the end of the process, all the tests would pass and the code would be very simple.
Test Driven Development Process
The core of TDD revolves around five steps. The goal of these steps is to ensure that the code is simple and efficient, while at the same time fulfills all the functional business requirements.
1. Add a New Test
The test should be as simple as possible. It should focus on testing a very specific aspect or component of a larger feature. Over time, many tests are created and will cover every aspect of the larger feature.
For example, let’s consider that we are building a user registration feature. A single test might be something like “email field is not blank.” Its purpose is simply to test that the email field is not empty when the form is submitted.
2. Confirm the New Test Fails
Once the test is created, the next step is confirming that the test fails. Why is this important? Because the code to pass this test have not been written yet. So, if the test doesn’t fail you have a bigger problem at hand. When you confirm that the test does fail and for the reason(s) you expect, you can be confident that the test is useful.
3. Write Code to Pass the Test
After confirming that the test fails, now it’s time for you to write the code that will allow the test to pass. The key idea here is to write enough code to pass the test and not write any additional code. The focus in this step is to create the simplest solution possible to pass the test. Note that the code produced will likely be very rough and not finalized, but that is okay because TDD encourages constant refactoring.
4. Confirm That the Test Passes
Once you’ve written the code, confirm that the test now passes. Back to the user registration feature example from step 1, this would mean passing in an empty email address would result in the test failing. Passing in an email address will result in the test passing.
5. Refactor
In the refactor step, the focus is to simplify the codebase. The process of writing the code necessary to allow the test to pass may have introduced some inconsistencies or duplication. This is the perfect time to locate those problem areas and fix them.
During this phase, you should also be re-running all previous tests to confirm that you haven’t accidentally introduced any additional bugs or broken an existing feature. This is commonly known as regression testing, which is confirming that functional code doesn’t break with new code additions.
6. Repeat All Steps
Usually, everything is kept small during the TDD cycle, which is why the process repeats over and over, with each test slowly incrementing the entire codebase, and slowly progressing closer to a completed feature. Throughout the TDD cycle, you would use small use cases, small tests, small code changes, small confirmations, and etcetera, which can possibly lead to only a few minutes.
Sometimes, the TDD cycle is also called the red-green-refactor. A red test is a failing test, while a green test is a passing test. So red-green-refactor, means to create a failing test, make it pass, and then refactor.
Test Driven Development in Action
Viktor Farcic has written a fantastic article about applying TDD in practice. To get a step-by-step example of TDD, I strongly recommend you to visit Viktor’s article about TDD.
Advantages of Test Driven Development
Here are some advantages to TDD:
- Considers the user experience: Writing tests first requires your brain to work backward. You first consider how the function will be used, then how it might be implemented, and then how a test that covers the implementation should be written.
- Can decrease overall development time: The frequent testing from TDD results in fewer bugs and prevent bugs much earlier in the development process. Since bugs were caught early in development, they don’t have a chance to affect the project later down the line.
- Reduces the reliance on debugging: Since TDD focuses on writing tests first, developers may find that a TDD life cycle can dramatically reduce the need for debugging.
Negatives of Test Driven Development
Here are some downsides to TDD:
- Requires additional time investment: TDD requires a significant upfront output of time and energy to come up with and write tests.
- Difficult to apply in all cases: TDD is great for small projects or small components and features of larger projects. Unfortunately, TDD practices may begin to falter when applied to massive or complex projects. Writing tests for a complex feature that you may not yet fully understand can be difficult if not impossible. In addition, when working with legacy code it is nearly impossible to properly integrate them into the TDD process unless they were also built with TDD.
I hope this post was helpful to you. If you found this post helpful, share it with others so they can benefit too.
What are your experiences with TDD? Have you been part of a team that uses TDD? What do you think of TDD in comparison to other Agile development methods?
To get in touch, you can follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.