(1) install database (or point to dev,) configure app, run seed data.
(2) creating the state in the database manually.
(3) change lines of code for feature
(4) reloading app, navigating through to the feature state, manually verifying.
(5) fix runtime errors or bugs
(6) Repeat as needed. Commit.
We don't need to swing around the entire stack to craft some pixels or make sure some message is displayed under specific circumstances. How do we get developers to think beyond this workflow?I think TDD at the very least is a education/comprehension exercise in abstract thinking which will discourage scenarios like the one described above. Once someone is able to TDD and 'gets it' then sometimes the way they approach arranging code even without TDD is better. I think this is why we may have mixed messages like "TDD is great!.. but we don't practice it at work."
Using a test harness any sorts to test something in isolation will speed things up. We can better understand where a module begins and ends (i/o, side-effects.) Develop it rapidly in the harness and then a few (automated) integration tests at the end. It doesn't have to be a TDD-specific testing harness.
React Storybook is an example of a UI test harness. It's still manual testing, but we get that great separation-of-concerns goodness that makes for better designed (and easier to maintain) systems.