Personally, I like to start with a big integration test.

Just use comments to map out the most complicated process front to back, the replace the comments with tests the whole way down (with no UI). I find that this approach plays really nicely with forcing you through a lot of architecture decisions.

Then, when that primary use case is working I’ll go fill in more targeted tests around different types of data in different pieces of the system.

And after all that, I’ll have a working and stable backend that’s ready for a UI.

Enjoyed this, love the passion.

My own take on TDD is that it’s a personal style. If you’re writing a feature, no one can “prove” that you followed TDD, you can write the whole feature and then retroactively write the tests, obviously. But on teams, precisely when we’re doing code review, I find it really helpful when there are unit tests to document how the logic is supposed to behave with various inputs. So I wonder why TDD is being linked so closely with the value of unit tests generally.

My other main thought is that FE development is fundamentally a different beast than BE. Writing elixir apps I find it almost trivial to add really good, but basic, unit tests (also 100% agree that “coverage” is at best a misleading metric). Mocking external factors in elixir code is so much easier than mocking UI state in a react app. I still find unit testing really valuable on the FE but it definitely extracts a steep price in terms of dev time, and that should be considered.