Most modern programming languages and development frameworks these days contain plenty of support for writing automated tests. For existing applications, you can find different testing libraries that plug into your current codebase. Frameworks such as Ruby on Rails, Django, and Laravel have automated testing baked in so you can write tests from the start. No matter what tools you use to build your apps, you can find what you need to create a test suite.

Despite the ease of automated testing nowadays, you'll likely find tons of projects with little to no automated testing. Often, the problem lies with the development team. Developers are notorious for not taking the time to write tests for their code, choosing instead of churn out new features and functionality, and deal with the consequences later.

As a developer, I've experienced this behavior in just about every place I've worked. It seemingly feels like developers who take the time to write tests are uncommon in software engineering. When I ask other developers why they don't include automated tests for their work, sometimes the answer is that they've never taken the time to learn how to do test automation. If they're eager to learn, it's an easy problem to correct.

Unfortunately, the more frequent response is "The organization doesn't give us time" or "Having to write tests slows me down too much, and I have a lot to do." The blame is solely placed on lack of time or having too much work on their plate - very viable reasons to skip writing tests. However, these reasons usually take the form of excuses instead of legitimate reasoning.

If you're a developer and have used lack of time as the reason for skipping testing, what if somebody told you that writing tests make you work faster, not slower? It sounds counter-intuitive; no one believes at first that writing more code will free up your time. But it does, both in the short-term and the long haul. The investment you put into building automated testing pays off big time.

This article goes through some reasons you might want to get into the habit of writing tests with your code, even when you think you don't have any time to spare.

You won't have to go through the entire application every time to test new changes

Imagine you're working on a bugfix or modifying existing functionality in an application. To get to that change, you need to execute a long list of steps in a particular order - create a new account, logging in as a user, setting up some prerequisite test data, and so on. Sometimes, doing all these actions to get to the sections you changed can take a few minutes. It's worse when you perform all the steps to get to your change, only to realize it's not working as expected, and you have to go through the whole process again.

If you spend some time writing tests alongside your updates - whether you use methodologies like test-driven development or writing tests after coding - you can use them to quickly validate your changes. You won't have to go through a drawn-out process to verify a small fix. It also helps you spot any areas you may have missed by getting a test failure. It's a lot easier to fix problems when the work is still fresh in your mind.

Be careful not to rely solely on automated tests, though. Automating to check your work quickly is not a substitute for manually verifying your changes behave well without breaking other areas. Automated testing isn't a silver bullet, and you always risk having a gap in your test coverage, especially when the test suite is still in its infancy. You should always take some time to test manually after your automated tests verify your changes.

Still, even when you have to test manually, automated testing will avoid the back-and-forth that occurs when your code changes don't work as expected. The feedback loop gets significantly shortened compared to only checking your work by going step by step through your application. The time saved in this process will pay off the cost of writing tests almost instantly.

It'll eventually save your rear end when you most need it

Every developer working in software development for a while has merged bad code to production, discovering the issue only after a customer sends an upset email to support. I'm not talking about logic errors or misunderstanding the project requirements. I'm talking about obvious errors - typos in variable names, improper closing of tags and blocks, anything that could get caught by automation if there's any coverage in the affected section.

One common reason for this problem is that many teams spend their time coding until the last possible minute. It makes testing everything manually almost impossible since these last-minute code changes often happen quickly and bypass most safety checks the organization has in place. Most developers have felt obligated to directly commit a hotfix without going through code review or QA. These are the times where those glaring errors sneak into your app.

This problem alone is an excellent reason to spend the time you need writing tests for your code. Automated tests are one of the best safety nets against those silly mistakes that happen during last-minute cases of "I need this one thing before deploying today" that appear out of nowhere. I can't count the number of times automated testing has alerted my team of potential problems, from the "that would have been annoying to our customers" issues to the "that would have killed our company" mistakes.

As mentioned earlier, automated testing isn't a silver bullet, and it won't always save your neck. If your app lacks enough automated test coverage, any untested changes at the last minute containing bugs will likely slip through. But the more automation you do, the more often it'll catch those defects. From the first time your tests detect a problem, it will make you feel like the time you spend on automated testing was completely worth the investment.

Tests serve as documentation for future team members

The primary use of automated tests is to help detect any regressions during the development cycle. As mentioned earlier, another advantage of these tests is they can help speed up the development process. However, an underutilized benefit of building an automated test suite is to serve as documentation for the team. The more test coverage you have, the more information about the application you'll share with others.

With a well-structured test suite, both new and current developers can read the test cases and put together how an application should work. Since these tests are executed frequently, either locally or through continuous integration, these test scenarios are often the most up-to-date documentation you'll have. The best test suites out there are structured to help developers also understand why some functionality exists.

Your tests can get new team members up to speed on their own by following the test suite. They'll learn what's going on in the application by example, and gives them the confidence to contribute quickly by experimenting and seeing how their changes affect the test suite. As a bonus, it also helps save the rest of the team lots of time from explaining their work since the tests are live examples that anyone can see and execute.

When you're building your automated test suite, remember that others can benefit from your test cases. Write thoughtful descriptions and make your code expressive enough that others can follow along with how the application behaves. Like the rest of the codebase, take into account that your tests won't only get read by a computer.

Summary

These days, there's no excuse to skip automated testing since modern programming languages and frameworks make it incredibly simple to do. Still, many developers cling to the thought that writing tests will slow them down when the opposite is true. You can find plenty of scenarios where the extra time spent writing code for automated tests speeds up your workflow.

You can save tons of time writing tests while you're developing new features or patching bugs. Automated tests allow you to validate that your work functions as expected without going through all the steps in your application to get to your changes. You should still test manually, but automation will significantly shorten the amount of time you need to do manual testing.

Automation will also save you when you need it the most. No matter how careful we are with our code, we'll inevitably break something. Even worse, we'll break something obvious right before a deadline, like missing an extra semicolon or forgetting to close a pair of brackets. An automated test suite can catch those simple issues on the spot and protect you from the stress of dealing with a broken production environment.

Finally, an automated test suite can serve as living, breathing documentation that's always up to date. Other team members can glance at the different test scenarios and figure out how the application should perform. A thoughtfully-documented test suite with useful examples lets others understand the system under test much more in-depth than only following the codebase.

Writing tests takes time - they won't write themselves, after all. But testing gives you a massive return on your investment. If you're still not sold on this argument, spend the next week writing tests alongside your work. I can almost guarantee you'll see the time you spend on them will pay off now and in the future.

Are you a developer that doesn't test because it slows you down? I'd love to hear different perspectives than the ones covered in this article - share your thoughts in the comments section!