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
Top comments (15)
I started writing tests before code about one year ago. Now I can't live without it.
The Test Driven Development approach makes so much more productive and gives me so much more confidence that I wish I had started using it earlier.
Man, I wish I had time to do TDD work, but the pace I need to make my deadlines won't fit.
(I've done TDD with some personal projects and enjoyed it despite working feeling sooooo slooooow, but in my day job I'm maintaining and adding to a large old codebase with no tests, because, man. No time.)
So true. TDD for greenfield projects sounds great. TDD for projects making enhancements on large legacy code bases that have little or no tests is much more difficult!
"DDT Development Driven Tests" are the stuff of nightmares.
I started applying TDD at work 9 years ago. I though it was worth the extra effort for all the reasons you mention and some more. So at first I was a big advocate of "Test first" like you. At some point though I had to give up.
I stopped writing test and for the last 3 years I have been much happier and more productive without them. I had written off TDD until I came across this tweet:
About 6 months ago I worked on an new project and I applied TDD once more, only this time I really enjoyed it! Just watch Ian's talk and you will get why. I couldn't have said it any better.
Never written a test in 20+ years of being a professional developer
dev.to/jonrandy/comment/92f8
Thought I'd seen this comment before.
For someone who hasn't written any tests you seem to want to make sure everyone knows you don't do it ;)
This is especially true in code-conversion work. You know what the intended logic is, so the tests can very easily be written before conversions are done. Good post 👍
I like the idea of writing tests for code I already know I'm going to test, but if I have no clue on how the code will look, I wont have any clue how to write the tests either.
Guess things come with experience :D
These are also all good reasons for doing requirements analysis before coding. A benefit of TDD for people who don't like to document.
One of the problems with TDD is that you might code to assumptions and then not have tests that try to break your coding assumptions. YMMV
Well for me, i write the implementation and write tests against it, i find this approach more effective, time and quality...
Agreed with how important it is to write tests first.
Just want to add, TDD and Test-First Development are similar but they have some subtle difference whose impact scales with the size of your project and team.
Ref: stackoverflow.com/a/48874859/3121906
Further reading: