4 Reasons You Should Write Tests First

Tests are met with varying opinions. Some developers hate writing tests and some don't mind it. There are a few key benefits you get when you write unit tests or any other tests that are subtle, but they exponentially improve the development cycle. Here's a few reasons why you should think about writing tests before you write any code.

It forces you (and the business side) to clearly define problems

It's not uncommon to have a project that has an ever-growing scope with… poorly defined user stories. You'll have to stop and ask questions about how the business side wants to handle a certain scenario and they end up telling you to do something that has nothing to do with the original task.

When you are writing tests first, you get all of those questions answered before you're deep into the code. It also gives you a way to somewhat control the scope of each task. You have to know exactly what a feature should be doing before you can write a test for it. This will give you a chance to ask all of the business questions upfront so that when you are writing code, you know exactly what you're writing and why.

If you ask the business side to define the problem they're having instead of trying to give you a solution, you'll be surprised by how much progress you make. Testing is going to ensure that you have those conversations because you won't be able to do any work without them.

It will allow you to write less code

You only have to write enough code to pass the test. Once it passes, you're finished with that part. When you're trying to implement a large feature, it's easy to get lost in the code. Testing keeps you on track and focused when you are writing the code for that large feature.

Before you can move on to another piece of the feature, you have to finish the one you're working on. There is no "coming back to it later" because you can't continue writing code until you pass that first test. It's like it slows you down so you can really think about what you're writing before you write it. Once you have a well-defined test, it's not as hard or complicated to write the implementation.

It will save you hours of debugging/maintenance/regression testing time

One of the biggest arguments against testing is that it takes too long. No one says much about time when it takes days to find out a logic statement was incorrect, but if it takes you a few extra hours to write tests then it's too much time. It's a whole lot easier to debug as you go because you are working on that one specific piece of code independent of everything else.

When you have to dig back through code and remember figure out what it is supposed to be doing, you're spending a lot more time. Having all of your tests defined at the beginning and writing just enough code to pass them clears up so many issues.

You can deploy your code on a Friday night and not worry about anything breaking. When you need to update a feature or you do find a bug, you can just check where the tests failed. Plus when you do any major updates or you just change a lot of files you won't have to worry about regression testing. A few hours of writing tests can save you from the worst of these issues.

It gives you a way to back up your word

Sometimes there's a disconnection between the business world and the developer world. Let's just say, users aren't always completely honest about what they did when something broke. With the tests in place, you can definitively show them that it's not your code.

Even if someone deploys changes without you knowing, the tests are there to save you. You will be able to show people that you had all of these tests in place and that a failing test would not get passed unless someone did something they weren't supposed to. Tests are like your safety nets because they keep you out of trouble by proving your innocence.

The way that users or QA testers can break things is impressive. By putting your tests in place and running through them each time you add new code, you are giving yourself clear documentation that everything is working as it should. No one else could give you this kind of definite proof that you were actually right this time.

How do you feel about writing tests before code? I started doing that for my personal projects about a year ago and it's changed the way I approach coding. Although I do still hear a lot of developers talk about how annoying or difficult it is to write tests. This is something I'm really interested in hearing from you guys about because the business side is usually not the keenest on you spending time writing tests.

Hey! You should follow me on Twitter because reasons: https://twitter.com/FlippedCoding