When Iâ€™m writing new software, one of the most important thoughts in my mind is how Iâ€™ll test to make sure it works. There are lots of ways to test software, and when youâ€™re at your best, you should be using all of them. Sure, you should make sure that your QA team is able to verify that your code works before it goes live. You should make sure that the code passes acceptance tests, too. In the best shops, youâ€™ll even have a robust suite of unit tests to ensure that small units of code behave the way that they should.
Lots of times, Iâ€™ll write some code, and then write a few tests to make sure that it works. Thatâ€™s not a bad system. But what would happen if we flipped that process on its head? What if we wrote the tests first, then wrote code that would make the tests pass?
Test Driven Development: Writing Your Tests Backwards
This method of flipping around how you write your tests is the core idea behind Test Driven Development. Instead of writing your code, you write your tests first. Then, even though you know they wonâ€™t pass, you run the tests. You watch them fail?
Because if your tests fail, you know that youâ€™ve written an effective test. If every test you write only ever passes, that can conceal subtle bugs which make your tests ineffective. I know that Iâ€™ve written tests before which always passed. When I ran my tests to ensure my code worked, I was operating under a mistaken sense of security. It turned out that my code didnâ€™t work, but I had no way of telling. My test had never failed, so I had no idea that it wasnâ€™t effectively testing my code. It took until some time later that I realized my error. Sometimes, the bug even made it to production before I noticed.
After youâ€™ve seen your test fail at least once, you write code that makes the test pass. One of the core tenets of Test Driven Development is that you write only enough code to make the test pass.
What Are Some Benefits of Test Driven Development?
In addition to the aforementioned benefits of writing your tests backwards, Test Driven Development provides other benefits. Like we mentioned before, thinking about how youâ€™ll test your code is a key part of building effective software. As a developer, one of your roles is to write software thatâ€™s easy to verify. You donâ€™t want to ship code only to find out later that it doesnâ€™t work. Catching defects early saves time and money.
With TDD, thinking about how youâ€™ll test your code is a core part of the code-writing process. Youâ€™re writing the tests for your code while you write your code. If youâ€™re an experienced developer, youâ€™ve probably experienced writing a big chunk of code. Youâ€™re pretty sure it works, but as you lean back, you have no idea how to guarantee that the code you wrote works the way you expect. With Test Driven Development, thatâ€™s never a concern. Youâ€™re building your tests right into the process of writing the code itself.
Writing Less Code With Test Driven Development
Another benefit of Test Driven Development is that you write less code. Remember before how we talked about writing just enough code to make the test pass? Thatâ€™s a key part of the Test Driven Development philosophy. As a developer, your job is to take your feature requests and turn them into testable features. Then, you write the tests for those features and finally the code that satisfies those tests. As weâ€™ve said before, the key is to just write the code that satisfies those requests.
The benefit here is that writing just the code that satisfies the tests means you write fewer bugs. Why? Well, the argument goes, developers are prone to writing more code than they actually need at any given time. I know that Iâ€™m guilty of this. Iâ€™ll often try to build a more robust, complex solution than the current problem calls for. These robust solutions often lie dormant, because weâ€™re not using all their features. Theyâ€™ll be useful â€œsomeday.â€ In reality, that code is often never useful. That feature I thought was so important at the time turns out to never be needed. Or, by the time itâ€™s useful, the parameters of that use have changed so that the code needs to be heavily modified before application.
This approach is an extreme variant of the â€œYou Arenâ€™t Gonna Need Itâ€ mentality. I know that as a developer, I regularly have to remind myself not to needlessly complicate my work by trying to solve future problems. Effectively adhering to Test Driven Development is a big benefit there.
Test Driven Development Means Easier Refactoring
Another major benefit to Test Driven Development is easier code refactoring. Iâ€™ve written enough code in my life to never expect that the work I do is permanent. I fully expect that every piece of code I ever write will be changed by someone down the line. It might be after Iâ€™m long gone, but itâ€™ll happen, someday. When that day comes, I want to make it easy for that future teammate (or my future self!) to know how those changes break code that relies on mine. This is another benefit of the TDD philosophy. The tests that I write for my code serve as a form of documentation. Itâ€™s also a contract with other parts of the code base. So long as my code continues to pass all the tests I wrote for it, that code behaves the way the rest of the code expects.
So, if someone ever needs to refactor my code, they can do so confidently. The same is true if their refactoring breaks one of the tests. It might be that they need that test to change! Itâ€™s OK to refactor things and for those changes to break code. With a broad suite of unit tests, like those proscribed by TDD, youâ€™ll know which behaviors of the code youâ€™re changing. Then, as the person making those changes, itâ€™s up to you to make sure you fix all the places that code is used.
Taking Test Driven Development to the Next Level
Test Driven Development is a powerful philosophy. Most developers that follow it truly write better code. But itâ€™s not enough on its own to deliver bug-free software. Youâ€™ll need to add more skills to your testing tool belt to deliver the best software that you can.
Thatâ€™s where a tool like Prefix comes in. Prefix works best in test-driven teams. It runs on your local machine, and works like a web-request profiler. But itâ€™s really powerful: it provides a lot more insight than an average profiler. Itâ€™s also really easy to read and understand the data it shows you. This means that if youâ€™re working with one of the languages it supports, like Java and C#, youâ€™ll find more bugs more quickly. Youâ€™ll also quickly identify bottlenecks in your code that are killing your performance. Even the best unit tests canâ€™t tell you why or where your code is slow. Using Prefix will give you visibility into your code that you canâ€™t get from tests alone.
Give Test Driven Development a Try
Test Driven Development isnâ€™t for everyone. Iâ€™ll be honest: I donâ€™t use it for every piece of code that I write. But I do find the lessons it teaches to be valuable in writing better, clearer, bug-free code. Itâ€™s a good idea for every developer to give Test Driven Development a try, for at least a little while in their career. Youâ€™ll learn how to build better tests, and how to trust those tests to write better code.
Is today the right day for you to take your first steps into Test Driven Development? I donâ€™t see why not!