Writing unit tests for personal projects? — FunFunFunction #29

Write your goddamn tests, always.

I’m actually more disciplined with unit tests for personal projects, because I generally care a lot about them, and since I’m writing them from scratch I have the luxury that I can structure them for testability.

I write tests because code without tests is buggy, bad code. If I’m not writing tests, I’m doing a bad job. Over the years, I’ve become more and more convinced that unit tests holds the same value as version control — it’s just stupid not to do.

Unit tests starts playing off very fast into a project. If you’re writing a teeny tiny script with only one execution path, that will only live for a week, then unit tests are overkill, but beyond that, you’ll save time. If you intend to spend a few weeks on something, tests will pay off (if you’re a somewhat experienced unit tester)

You just have no idea how many things that can break until you start writing tests for your code. It’s remarkable. I’m currently looking at a relatively small piece of code that does scroll management that I’ve written at Spotify. It’s slightly above 250 lines of code, and it has 137 tests, and I’m pretty lazy with adding tests — only the bare minimum here, no triangulation or anything. If you’re only doing manual testing, you’re probably regression testing 3–4 cases every time you do a change. A ridiculously disciplined person might do 10. The fact is, if you’re writing code without a test suite checking it, you’re going to break a lot of things that worked at first along the way.

Unit testing sometimes feels frustrating because it makes you slower when writing new code, but it will still make you much more productive overall. The reason is that after the initial few weeks of development, the vast majority of the time you spend in a project is going to be spent making changes in existing code, and that can be done easily 10 times faster when you have an automated test suite helping you.