←back to thread

Delete tests

(andre.arko.net)
125 points mooreds | 3 comments | 27 Aug 25 11:18 UTC | HN request time: 0s | source
Show context
recursivedoubts ◴[30 Aug 25 02:27 UTC] No.45071410[source]▶
One of the most important things you can do is move your tests up the abstraction layers and away from unit tests. For lack of a better term, to move to integration tests. End-to-end tests are often too far from the system to easily understand what's wrong when they break, and can overwhelm a development org. Integration tests (or whatever you want to call them) are often the sweet spot: not tied to a particular implementation, able to survive fairly significant system changes, but also easy enough to debug when they break.

https://grugbrain.dev/#grug-on-testing

replies(11): >>45071535 #>>45071726 #>>45071751 #>>45071944 #>>45072117 #>>45072123 #>>45072158 #>>45072321 #>>45072494 #>>45074365 #>>45080184 #
strogonoff ◴[30 Aug 25 06:16 UTC] No.45072321[source]▶
If there is one single test-related thing you must have, that would be e2e testing.

Integration tests are, in a way, worst of both worlds: they are more complicated than unit tests, they require involved setup, and yet they can’t really guarantee that things work in production.

End-to-end tests, meanwhile, do show whether things work or not. If something fails with an error, error reporting should be good enough in the first place to show you what exactly is wrong. If something failed without an error but you know it failed, make it fail with an error first by writing another test case. If there was an error but error reporting somehow doesn’t capture it, you have a bigger problem than tests.

At the end of the day, you want certainty that you deliver working software. If it’s too difficult to identify the failure, improve your error reporting system. Giving up that certainty because your error reporting is not good enough seems like a bad tradeoff.

Incidentally, grug-friendly e2e tests absolutely exist: just take your software, exactly as it’s normally built, and run a script that uses it like it would be used in production. This gives you a good enough guarantee that it works. If there is no script, just do it yourself, go through a checklist, write a script later. It doesn’t get more grug than that.

replies(3): >>45072426 #>>45072459 #>>45072518 #
1. ivanb ◴[30 Aug 25 07:02 UTC] No.45072518[source]▶
In practice e2e tests don't cover all code paths and raise a question: what is the point? There is a code path explosion when going from a unit to an endpoint. A more low-level test can cover all code paths of every small unit, whereas tests at service boundary do not in practice do that. Even if they did, there would be a lot of duplication because different service endpoints would reuse the same units. Thus, I find e2e tests very limited in usability. They can demonstrate that the whole stack works together on a happy path, but that's about it.
replies(2): >>45073227 #>>45082446 #
2. strogonoff ◴[30 Aug 25 09:24 UTC] No.45073227[source]▶
You are testing that the software works. I think that is higher value than testing all possible code paths in isolation, and then still not having the guarantee that it all works.
3. stavros ◴[31 Aug 25 11:46 UTC] No.45082446[source]▶
The problem tends to be that programs most often break at the integration boundaries, though.