Mine is that the useState hook is an actual plague on the entire React ecosystem. Regardless of your opinions of React, if you wanna use something then use it right.
Mine is that the useState hook is an actual plague on the entire React ecosystem. Regardless of your opinions of React, if you wanna use something then use it right.
Unit tests are overrated to the point of being harmful. They have their place, but that place is certainly not “the base of the testing pyramid”. They are useful for a very specific type of “units” - and using them anywhere else just messes things up.
The point of unit tests isn’t that the tests are important, it’s that using them makes you write your code in testable units.
Curious how bad they’d have to be to land you at that position.
If they’re hard to write, it’s kinda a red flag about the overall code itself. Forcing people to write them tends to force people to use better patterns just so the associated tests aren’t a bitch.
And they pin behavior more than strict correctness, in my experience, but that’s a valuable signal. Canaries in the mine.
You can be much more bold when you’ve got strong coverage.
So I do admit some of the benefits might feel intangible… But boy howdy you’ll miss them if you move to a shop that never bothered. You’ll see the dumbest fucking patterns and be kinda handcuffed to do anything good.
The problem is that the behavior they pin is not the official API-exposed behavior. The behavior they pin is mostly implementation details. If
diffuse(bomb)is supposed to diffuse the bomb, I need to test that given a legal instance of aBombit’d end up diffused. A unit test cannot test that - ifdiffuseis the unit being tested, thenbombis not allowed to be an actual bomb - it has to be a mock. And thusdiffuse(bomb)does not test thatdiffusediffuses a bomb - it tests thatdiffusecuts very specific set of wires in a very specific order.diffuseto handle the new bomb, the unit test becomes red.Once the bomb change, the unit test shows the opposite of what a test is supposed to show - and now you have to fix the test itself. Because that’s what unit tests test - they test themselves. They don’t test the system.
An integration test that would bring in an actual bomb, diffuse it, and check if it’s diffused in a controlled environment where it can’t do damage by blowing up - is going to be more expensive to run, yes, but at least you will be getting a meaningful signal out of it. It’d be testing something of value. The unit test is cheap to run (although writing it was probably more expensive), but it gives you nothing. It’s completely pointless.
Awesome and well articulated response. Love it.
There are a few threads to pull here:
Is an integration test the best way to test the full e2e behavior of an api call? Yep.
Now, depending on the size (and architecture) of your system, the full test suite of into tests could take like, 10 hours.
And even then, you’re STILL probably mocking something (direct seeding bombs into the db). Full setup of all life cycles of all your entities using their associated entities (bombs, wires, wire clippers, bomb diffusers, their rank, their bosses, their diffusion history, etc…)
So they’re expensive, and if you really look you’re probably still cheating some steps anyways.
Another thread to pull on is what are you mocking in your tests to begin with, and if they’re not resulting in valuable test results then that goes back to one of my original points being that you might have suboptimal patterns in your production code.
Like, what logic governs bomb diffusion and where does it live? Are you mocking the right thing? If you have to mock the wrong thing… WHY? The ritual of writing those tests give you the first whiff of a potential smell.
I tell my guys not to test implementation: test behaviour. Test contract adherence. If that’s hard, no problem, message me let’s review it. Maybe a behavior they’re trying to test legitimately should be an int test. More often than not, their design is demanding to mock something that should be decomposed further, and then composed with dependency injections that are where the units that should ACTUALLY be mocked are the things that get mocked and injected, so the unit tests are actually testing the BEHAVIORS we want to pin rather than implementations. Composition and single responsibility principal are what enable unit tests to pull their weight.
Edit: I’m so passionate on the subject that if you scribbled up a scratch example and pinged me a github link I’d genuinely review it.
Unit tests are good IMO, but integration tests are also important. Unit tests are too discrete and don’t expose system wide issues that cross the boundaries of what you’re testing at the unit level. Examples: performance, stability, memory leaks, bugs that are caused by how multiple components interact with each other, etc.
The other thing is that I think people use tests to give a false sense of security. Tests cannot expose issues that aren’t explicitly covered by testing. Design validation is still important and people tend to overlook that because of the false sense of security they get from seeing a test suite pass.
I’ve come around to this position after seeing the mess people make.
I just got a new job where I contribute to a fancy open source database. They do have unit tests. Barely. Most things are tested in SQL though. You have to build/link the whole thing to run the tests. But lots of things are plugins so it’s fast enough.
If you can get away with it, this is better.
I’m so heartbroken by the idea of unit tests. My first job was at a home automation startup and our primary product was a device that we would send ota firmware updates to. The device was based on an esp32, and because it received software updates from the app it had to be 100% robust and had full test coverage and the mono repo that would compile the firmware was gorgeous.
I’m a web developer and I’ve been wanting to replicate that exact experience ever since but I just can’t get any team on board. It’s gone to the point where if the llm writes a unit test I’ll just commit it so I don’t care.