Don’t write tests to catch bugs
It is widely accepted fact among programmers that writing tests is good practice. But writing tests also has a reputation of being difficult, time-consuming, redundant, pointless, and boring. This story aims to change that.
Writing tests saves time
Probably the most popular reason you hear for not writing tests is that it is a waste of time. That’s not true. In programming we often follow this pattern of manually verifying if the code written works as intended. This happens quite often. In fact every code block or so. You don’t actually have to follow this pattern. Tests can do it for you. This can save you a lot of time. A lot.
If each test saves you at least one sec of manual checking, 20 checks save 20 seconds, and you check 15 times while solving a problem. That adds up to 6 minutes. Now, imagine if you have 5 people working on your project you’ll save 30 minutes for your team. Not bad at all.
Tests reduce the time required for code reviews.
Consider the amount of time actually spent on code reviews, and PRs. Manually checking each line of code and verifying it not an easy job. With tests you can save this time and just read your test specs. If the tests pass, merge PR.
If you don’t have that much time to write tests I’d recommend writing at least integration tests. Treat integration tests as smoke tests. If there is smoke then you can start looking for the fire. Integration tests are always better than no tests at all. At least they tell you there is a fire even if it is vague in telling you where it is.
Don’t write test to catch bugs
Many programmers believe tests are written to catch bugs. That’s not true. Tests check for regressions. Tests actually prevent programmers from introducing new bugs into working code.
Many programmers believe tests are written to catch bugs. That’s not true. Tests check for regressions.
You can never write enough tests to cover all your edge cases. Simple reason being that code you write will not always used the way you originally intended for. That’s why you should always write tests to prevent regressions.
Tests free your mind
I often find myself spend more time reading than writing code. Programmers often have to keep lot of things in their mind while adding new features or fixing bugs. This can quickly escalate as your codebase grows or becomes complex. Tests can free up this mental space.
Tests are easier to write than actual solution
Many programmers have unreasonable fear for writing tests. They believe writing tests is hard. True, if you are not used to this process. However, just as with any type of coding it gets easier with time. Eventually writing tests will become your second nature. Believe me Tests will become easier to write than the actual code.
Tests make refactor easy
Every codebase reaches a point where some code becomes out-of-date and needs to be refactored. It can be quite dangerous refactoring without any tests in place. With tests all you need to do is re-run your test suite. Tests also make it easy to update your dependencies easily. If I had a dollar for every time I wouldn’t upgrade my dependencies for the fear that I’d break my app. I’d have a lot of dollars.
Tests prevent production rollbacks
Your users are not supposed to be your testers. Releasing buggy software can cost you your users. Earlier you can find a bug, the cheaper it is to fix. Tests can avoid those dreadful late night production rollbacks.
I hope this post helped change any notions that you have about writing tests. Happy testing!
