Testing is an integral part of the software development process. As development teams are being asked to build more features, the pressure to write bug-free code also increases. However, in building a testing culture, it is not always clear when developers should write tests. On one hand, it is believed that tests should be written first to ensure the implementation stays focused. On the other, writing code first helps to uncover edge cases that might not have been known before coding.
Let’s examine the pros and cons of both approaches. But first, it’s worth discussing test-driven development (TDD).
What is Test-Driven Development?
TDD is a form of software development where tests are written before coding. A typical flow looks like this:
- A test is written that fails since the implementation hasn’t been written.
- The simplest implementation is written to pass the test.
- The code is refactored and improved, as necessary.
These steps are repeated until an entire feature is completed.
Although most TDD tests are unit tests, it is not uncommon for development teams to write integration or end-to-end tests here. The benefit here is that when the tests pass, the feature is also complete and ready for production.
What is Behavior-Driven Development (BDD)?
BDD takes a step back from TDD and focuses on the team aspect of testing. Instead of the engineering team in charge, product and quality assurance (QA) can help set the standard of what is acceptable. This helps the different teams collaborate on complex features and ensure that stakeholders are on the same page. With BDD, the main difference is that QA teams write out the end-to-end and acceptance tests that are required to pass before engineering can mark a feature complete.
It’s worth noting that there are other variations of TDD and BDD that have emerged, but these two philosophies are currently the most used.
Pros of test-driven development
Now that we have an idea of TDD, it’s time to list out some of the reasons to use this approach when writing tests.
-
Write less code
Writing tests first ensures that the code written afterward does the bare minimum. This prevents over-architecting in your codebase. -
Easy refactoring
Since you have written all your tests ahead of time, you can be more confident that changing code around improperly will fail your tests. -
Automatic high test coverage
Although we don’t always advocate for 100% code coverage, it’s still important to have high test coverage to avoid more obvious bugs. -
Tests are ensured to run
When you use something like TDD, you know that all of your tests are running since they, at one point, show as failing. This helps prevent false positives when running a large test suite.
Pros of test-later development
Testing after code is written is known as test later development (TLD) and is the other side of the testing philosophy from TDD.
-
Better edge case tests
After code is written, a developer may have a much stronger understanding of how a particular function or set of functions work. Writing the tests afterward helps them to outline possible edge cases. -
Fewer trivial tests
Because tests aren’t written with the sole goal of passing beforehand, you are much less likely to have trivial tests in your test suite. -
Shorter development time
Using TLD over TDD allows for faster product development. Writing tests after you code focuses the engineering team on the codebase instead of switching between code and tests.
Choosing between TLD and TDD
So which one should you and your development teams use? If your product is in exploratory phases or the company is an emerging startup it might be best to use Test-Later Development to allow your team to move quickly. But it is worth switching to TDD or a similar approach if you have the time to dedicate to a testing culture.
Although we explored some reasons behind writing tests before and after you code, there are still some considerations to make in writing good tests. Inevitably, your code will continue to grow and change, and so will your tests. Aside from writing a comprehensive test suite (that covers all of your code hint, hint), the next most important thing for good tests are those that are maintainable and readable. Like all code, tests should be easily understood. Keeping this in mind will help your codebase scale with your product.
