Yeah, I've found I'm starting to write fewer, and coarser tests and it is good for the code base. You can always augment them with bugs later on. And if you can

Yeah, I've found I'm starting to write fewer, and coarser tests and it is good for the code base. You can always augment them with bugs later on. And if you can isolate the main logic of a system into small components extended by addition over modification, even better. In most of the small systems we're developing at work, I tend to have 2 groups of tests: One testcontainer driven test testing the actual database layer. These tests are very simple and small - migrate the database, call insert a few times, load objects back and compare them. Nothing more. And the other tests are usually more of the nature of "Given these elements in the database, expect that output for a REST call", augmented with a few tests of some fiddly functions. The other thing I meant occured for example in a stream processor, which needed to apply different transformations to incoming messages for normalization, default values, precomputations and so on. Here we reached a point of confidence where each of these processors was tested as a stream to stream mapping in isolation. It was pretty and it worked wonderfully and without issues. If you can achieve this kind of system of pretty much functional components and extension by addition, that's very much a pinnacle of testability.