[ajmurmann]

I still recommend to stick with outside-in TDD. It will help you discover interfaces and not over-engineer them. However, don't get too hung up on fulfilling that outermost feedback loop and test immediately. It's OK to spend a lot of time on one of the inner components and commit that and its tests before moving on to the next piece you need to get the outermost test to pass. In fact, it's a great way to make iterative, committable progress towards the larger goal. I know it can feel weird to not get back to the outermost test for a long while, but that just means that your user intercase is simple, but a lot of work is behind the scenes. Nothing wrong with that.

Another piece of general advise on TDD: Adjust what tests and how many you write based on what your language already gives you. E.g. when I write Ruby or JS, I'll write a ton of unit tests for almost Avery conceivable scenario. When writing Rust or Swift I write mostly unit tests for interesting business logs, but not much else.