←back to thread

Delete tests

(andre.arko.net)
125 points mooreds | 1 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 #
yeswecatan ◴[30 Aug 25 03:46 UTC] No.45071751[source]▶
I find testing terminology very confusing and inconsistent. Personally, I prefer tests that cover multiple components. Is that an integration test because you test multiple components? What if you system is designed in such a way that these tests are _fast_ because the data access is abstracted away and you can use in memory repositories instead of hitting the database?
replies(2): >>45072013 #>>45072858 #
1. jessekv ◴[30 Aug 25 04:58 UTC] No.45072013[source]▶
I think it's relative, right? That's how abstractions and interfaces work.

I can write a module with integration tests at the module level and unit tests on its functions.

I can now write an application that uses my module. From the perspective of my application, my module's integration tests look like unit tests.

My module might, for example, implicitly depend on the test suite of CPython, the C compiler, the QA at the chip fab. But I don't need to run those tests any more.

In your case you hope the in-memory database matches the production one enough that you can write fast isolated unit tests on your application logic. You can trust this works because something else unit-tested the in-memory database, and integration tested the db client against the various db backends.