Unpopular opinion: unit tests are often overrated.

Although a well written test suite is almost essential in some parts of the application (I.E. business logic) I cringe when I see hundreds or thousands of line which “mocks” everything to test a micro service which just does CRUD operations on a database, in cases like that unit tests are just a waste of time because almost every operation involves a mock which may not behave like the real database and often needs to be rewritten when the code undergoes a huge refactoring. In these case a integration test suite is faster to write and way more helpful.

In many cases i feel that you can skip unit tests if the feature is not too large and the code you are testing is specific for the that specific feature. Then you can just use feature/integration tests.

If its a really big feature however i feel that the integration test suits becomes way to huge if you are to test every scenario possible from a top layer.

But if you use unit tests i think you should be careful with mocks and shouldnt "mock what you dont own" since you can get a lot of false positives since you are mocking an api that might change.

If you follow TDD and write the tests first, your code will be more testable. You'll think of how best to organize things with that focus, and it winds up being more maintainable.

You'll also learn the parts you can't test well, and you'll know to skip them in advanced.

Many times you'll realize the design you had in your head will be insufficient, and a different pattern will be better fitted before you even write a longer of code.

Yes, unit tests are great but too many devs don‘t get them right. Aiming for some % test coverage is nonsensical. Unit tests should only cover what makes sense, and code should be written to be testable. But some folks just overdo it and test way too much. Then it becomes testing for the sake of testing.

I’m frustrated, I’m studying a 500+ pages technical manual but today I progressed of just 5 pages in 45 damn minutes. Do you know where I can get a replacement brain? Because mine seems to be basically an useless paperweight

@Lensflare Well.. JS devs have a strong incentive to approach 100% test coverage: it influences the "quality" rating of your NPM package. It's a bit vain because you could add // ignore-coverage comment lines everywhere..

So I took over as lead for https://metalsmith.io SSG a few months ago and was able to pick up fairly quickly and eliminate doubt thanks to the rigorous unit test suites. I'm supergrateful to the previous maintainers that they took good care. Without that, I would've perhaps introduced breaking changes to edge cases without realizing it.

On the other hand I fail to see the utility for batteries-included unit-testing for UI (with a virtual dom, Jest snapshots, pdf renderer, etc)

@DEVil666 a good way to do API unit testing is to do live requests locally, save their resp. As snapshots, and version control those snapshots (for CI tests). There is no need for mocking every request, you simply swap out the HttpClient generic request method (& you can easily simulate latency & errors too)

@webketje the is the shit that I‘m talking about. It leads to millions of tests testing if a value assigned to a variable is the same value when read from that variable in the next line.
For the sake of 100% test coverage!

I partly agree with this point of view. Writing unit tests is too cumbersome, especially for small services that only perform simple CRUD operations. In these cases, integration tests will be more effective, both faster and closer to reality.

However, I still believe that unit tests are necessary, especially for components that handle complex business logic. These unit tests help ensure that functions and modules work as expected, thereby minimizing the risk of refactoring later. Therefore, there needs to be a reasonable balance between unit testing and integration testing, depending on the characteristics. nature and complexity of each component in the application.

It generates millions of tests to see if a variable's value matches the next line's reading.

For 100% test coverage.