Not writing unit tests just isn’t an option for a reliable app in the long term. But, it’ll take way more than 10 minutes, always.

Not testing is crazy. Once you realize you can actually refactor without ever having the fear you’ve broken something, there’s actually opportunity to make rapid improvments in structure and performance. Taking 2 minutes to write the test can save your hours of debugging. Unless you’re building a throwaway prototype, not unit testing is always the wrong choice.

I like to tell myself “the scope of the feature is simple enough that it’s unnecessary”

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 😅.

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.

At least for frontend development, with new faster e2e testing frameworks that can even record the test while you see your work in a browser, lately I’ve been feeling I want to write more e2e tests and less unit tests.

That’s why you write the tests first