While I agree testing in general is a must, I'm still not sold on unit testing as a general tool.
For stuff like core libraries or say compilers, sure, unit tests are great. But for the levels above I'm leaning towards integration tests first, and then possibly add unit tests if needed.
After all, you can't not have integration tests. No matter how perfect your Lego bricks are, you can still assemble them together the wrong way around.
I tend to think that the most valuable tests are on the exact level of when something gets used by multiple consumers.
So shared functions get unit tested, but if there is a non shared function that gets triggered only from few layers up via user click, it is better to simulate that click and assert accordingly. However the exceptions are when the input can have tons of different permutations, when unit test might just become more optimal then.
Yes exactly. If you're writing a library, unit tests are likely a great investment. Your "customers" are using the things you are testing.
If you're writing an API, your customers are calling the endpoints. Very important they behave properly on happy path and fail appropriately when they should (permissions / security especially)
(I also ensure tests in the service/dao layer to protect developers from footguns and/or more "unexpected" behavior, but I'd argue the API layer is generally more important)
If you're writing a react app, playwright is very important (and using it properly / acting like a real user) as your customers are interacting with it via a browser.
Though the larger the codebase/ when you start having reusable components, the better tested they are, the less will go wrong in the future as an unfamiliar developer will inevitably hold it wrong.
Agree - unit tests are best for pure functions and the like. If you are having to do a ton of mocking and injection in order to unit test something, it's probably a sign black box testing might be higher value
On every large codebase I’ve worked on , updating a low level function has required more work updating the tests than updating the application using it.
Unit tests have a place, but IME are overused as a crutch to avoid writing useful bigger tests which require knowing what your app does rather than just your function.
> Integration test are slow/expensive to run compared to unit tests and reduce your iteration speed.
My unit tests might take under a second to run but they’re not the ones (IME) that fail when you’re writing code. Meanwhile, integration tests _will_ find regressions in your imperfect code when you change it. I currently use c# with containers and there’s a startup time but my integration tests still run quickly enough that I can run them 10s or hundreds of times a day very comfortably.
> If you’re doing a lot of mocking then your design is not good.
This is the “you’re holding it wrong” argument. I’ve never seen a heavily unit tested codebase that didn’t either suffer from massive mocking or wasn’t decomposed into such small blocks that they were illogically small and the mental map of the project was like drawing with sand - completely untenable.
> And only public interfaces should have testing.
This is the smoking gun in your comment - I actually disagree and think you should infer this. Services (or whatever you call them) should be tested, and low level functionality should be tested but the stuff in the middle is where you spend 80% of your time and get 10% of the benefit
> Unit tests let you change code fearlessly with instant feedback.
Sure they can add confidence in making changes. But I've seen they can also give you false confidence.
As I said, I can still assemble your perfect Lego bricks together wrong. And you can still change the public behavior while keeping your unit tests passing fine. I've seen both happen in practice.
That's why I think integration tests (or whatever you want to call them) give you more bang for your buck. They give you even greater confidence that your stuff works, and generally you can cover a lot more with far fewer tests so improves ROI.
The tradeoff is that it can take a bit longer to run.
> If you’re doing a lot of mocking then your design is not good.
If my app needs to talk to a database, store things in object store, send some messages in a message queue and so on, I can't not mock those things away if I'm to write unit tests.
I think in general tests should be where errors and mistakes are more likely to occur. Different code bases could be different! Hard core math libraries are different than a web app with various integrations.
For stuff like core libraries or say compilers, sure, unit tests are great. But for the levels above I'm leaning towards integration tests first, and then possibly add unit tests if needed.
After all, you can't not have integration tests. No matter how perfect your Lego bricks are, you can still assemble them together the wrong way around.