Where I hit this all the time is when people have written various flavours of queues and item processors all wrapped up into one, where a timer or similar mecha

Where I hit this all the time is when people have written various flavours of queues and item processors all wrapped up into one, where a timer or similar mechanism will trigger an item(s) to be processed. For example, a denouncing queue where you can add items to it, and it will pause a bit to allow other items to accumulate in the queue that can be processed in a single batch. To test the item processing well, you need lots of different tests covering all the branches in the logic. But to trigger the processing you need carefully timed code full of sleeps. Combine the two and you have lots of painfully slow tests. Move the logic out so you can test that nice and fast, then have a handful of slow tests checking the queue mechanism works. Contrary to some of the other comments here, I don’t think that’s designing your code specifically for your test framework. The logic of how you coordinate processing is a separate thing to the logic of how you process it. So splitting those concerns apart is good design regardless.