All you folks are crazy not to unit test personal projects. Unit tests don’t need to be fancy and exhaustive. A sanity check and having a simple way to execute isolated code is well worth the 15 minutes of setting it up. Heck, just use them as scratch files to try out libraries and APIs. I can’t imagine having the kind of time to raw-dog that f12 button and sifting through print() nonsense all night.
I think it also very much depends on your tooling & how easy it feels to start writing unit tests.
When I work in a Java project for example I always write unit tests even for personal stuff, because the IDE integration is great and it’s really quick to create a test class, run it and see granular results. I don’t feel the same way about testing JavaScript because the tooling at least for me hasn’t worked quite as well (though that could very well be my own fault, it’s been a while since I looked into it). The more cumbersome setting up and running the tests is, the more tempting it becomes to just use the console or manually test parts instead.
One rule of thumb I’ve heard and follow is that every time you encounter a bug, you write a unit test that would catch it. I find that does a pretty good job of getting high code coverage, though maybe that’s cause my code is naturally buggy 😅.
- Writes test to trigger the bug
- Test is green without fixing the bug.
- Dafuq?
I’m a frontend developer. All the meaningful tests always break for the stupidest, obscure reasons. That’s why I don’t write tests.
Here’s my take. In order to be able to write meaningful unit tests the code should be structured in a certain way, with very modular, decoupled units, dependency injection, favoring composition and polymorphism over inheritance and so on.
If you manage to write your code this way it will be an objective advantage that will benefit the project even if you don’t write a single unit test. But it does make unit tests much easier to write, so presumably you’ll end up with more tests than otherwise.
IMO teams should prioritize this way of writing code over high test coverage of non-modular code. Unit tests for deeply-coupled code are a nightmare to write and maintain and are usually mostly meaningless too.
This. Just thinking about how you would test something leads to better code, at least in my experience.
