Learn automated testing
If you want to build good software, learn automated testing. Depending on your platform of choice, you may have good defaults or you may need to investigate options. But I think of a test suite as a “fat suit” for your code. Sure, your code can still “fall down”. But it will hurt much less.
Automated test code is still code, and that means that it has a cost. You need to maintain it (both with infrastructure and developer time). I worked on a project once that had so many tests it felt like when you made a small change to the code, you spent most of the time updating tests. That is not optimal, and those tests could be refactored. You should count on spending some time working on your test suite, but I do feel that things that may be red flags in production code are OK with test code (just because that is supporting infrastructure).
On the project with the many tests, we knew when things broke because of all those tests. And we felt comfortable changing complicated logic knowing that edge cases were handled.
On another project I wrote a lot of tests and any time there was a bug that came in for a particularly complicated piece of code (it dealt with payments), I made sure to write a test for that bug. That’s the biggest win: tests can save you from regressions. It is not very much fun to fix a bug and have it pop back up six months down the line. Writing an automated test will keep that from happening.
Tests are also living documentation, as long as they are run regularly. (Please set up continuous integration!). They will help new developers get up to speed on a project, since the new developer can tweak something and get instant feedback (rather than having to try to find where in the user interface to go to activate that code path.)
It takes a while to understand the right way to test. There are books to read, and examples to follow. My experience is mostly “on the ground”. I favor unit testing anything that is complicated to understand or may change. I favor integration testing important pieces of your application. I favor knowing what your platform provides and leveraging that. I favor using continuous integration on every branch. But I realize that every situation is different.
A special note about UX. Don’t test UX that isn’t important. And realize that UX is often a piece that breaks and is hard to test. I recommend starting with something easier, on the backend or in pure logic. Functions that do things like split up strings are a great place to start.
However, the most important thing is to start. If you have a project that doesn’t have any testing, make that investment and do the first test, even if it is trivial (“can I instantiate this object?”). And force yourself to write tests even when you’re slinging a lot of code. It will help future you, I promise.
This article first appeared at https://letterstoanewdeveloper.com/2019/04/29/learn-automated-testing/