> When I'm building web apps at home though, like I always do at work, how much of it do I write unit tests for? Zero. I can't quantify why. I just know intrinsically that they're useless and it's a waste of time.
Serious, not-loaded question for you BigJono:
At work, do you (or your team) primarily write unit tests or integration tests?
Until my current job, I spent the first 5 years of my career writing unit tests in OOP systems where I injected mocks of dependencies. I realized in hindsight that these are basically useless. You end up proving very little about the code.
At my current position, we do primarily integration tests. (Have a test DB, essentially run code "end to end" minus the HTML UI.) These tests are _very_ helpful. Have stopped me from creating bugs dozens to hundreds of times. (Over a few years.) Same with other co-workers.
It's worth mentioning the product is a large monolith though.
I will write "unit tests" but they will be at the level of a whole module or assembly, and so often blur the lines with integration tests (particularly because spinning up a test data store is often easier than buggering around with mocks).
"Real" integration tests look at multiple modules or systems.
You catch a lot of bugs this way, have far fewer tests to maintain, and have the freedom to make internal changes without worrying that you're then going to have to fix up 100 tests to get your build working again. And you still get the coverage you need.
It's a better world.
Tbh, I find writing a tests at the class or method level only to be absolutely ridiculous except for cases where I'm dealing with a method that does something particularly tricky or esoteric.
Again, for all this context is key. As developers we should be thinking about what we're doing and the trade-offs inherent in that, not just blindly following a set of rules that say "You should do X; you should unit test; you should write tests for every method of every class."
Serious, not-loaded question for you BigJono:
At work, do you (or your team) primarily write unit tests or integration tests?
Until my current job, I spent the first 5 years of my career writing unit tests in OOP systems where I injected mocks of dependencies. I realized in hindsight that these are basically useless. You end up proving very little about the code.
At my current position, we do primarily integration tests. (Have a test DB, essentially run code "end to end" minus the HTML UI.) These tests are _very_ helpful. Have stopped me from creating bugs dozens to hundreds of times. (Over a few years.) Same with other co-workers.
It's worth mentioning the product is a large monolith though.