Test-Driven Development


Test-driven development (TDD) seemed odd to me when I was first introduced to it, much like the majority of others. The idea of writing tests before code felt weird in a way, as you write tests for nothing. However, the more I read about the benefits and how to properly apply TDD, the more obvious it was how useful TTD really is. Jacob Schmitt does a great job explaining TDD along with its benefits and best practices in his blog “Test-driven development (TDD) explained” (https://circleci.com/blog/test-driven-development-tdd/).

Test-driven development is a software development approach where tests are written before code. It follows an iterative cycle: write a test, ensure it fails, write code to pass the test, and refactor. This means that a large amount of planning needs to go into the start of a project. Designing tests requires an understanding of what the feature you are adding should accomplish. This includes testing that things should pass when expected and fail when expected.

As I mentioned before, it feels counterintuitive to write a test for code that does not exist. That is, until you understand the benefits of having tests. Tests are going to be required for any serious project. Having the tests written first will greatly increase your chances of finding bugs as early as possible. This also ensures that any refactoring does not break any existing functionality. This is great when working with a team, ensuring that everyone is on the same page and that changes made by anyone will be tested. TDD also ensures that all code that is written is tested. This greatly increases the code reliability and ensures functionality aligns with the user expectations.

One of the most impactful benefits of TDD as a developer is the increased confidence that any changes you make in the code will have immediate feedback on if it passed the tests or not. This confidence extends to every developer on the team, as these tests ensure everyone’s code works as intended.

Catching bugs early can save a huge amount of time and money. It makes sense that testing code incrementally as it’s added is better than waiting until it is all developed to test. This also makes sure no code is ever added that isn’t tested. Meaning tests are being rushed near the end of deadlines, and potentially missing some.


Leave a comment

Design a site like this with WordPress.com
Get started