Agree w/the author that the concept of "unit" often hurts test quality. You should be striving to balance the long-term usefulness of your tests with the debug

Agree w/the author that the concept of "unit" often hurts test quality. You should be striving to balance the long-term usefulness of your tests with the debuggability of those tests. In my experience, those tests are what most people would call "integration tests" (although that name, like so much terminology in the testing world, is confusing and poorly defined.) You want to get the tests up at as high a level of abstraction as possible where the API and correctness assertions are likely to survive implementation detail changes (unlike many unit tests) while at the same time avoiding the opaque and difficult to debug errors that come with end-to-end testing (again, the language here is confusing, I assume you know what I mean.) See https://grugbrain.dev/#grug-on-testing https://grugbrain.dev/#grug-on-testing