>One test. A really truly automated test, with setup & invocation & assertions (protip: trying working backwards from the assertions some time). It’s in the wri

>One test. A really truly automated test, with setup & invocation & assertions (protip: trying working backwards from the assertions some time). It’s in the writing of this test that you’ll begin making design decisions, but they are primarily interface decisions. Some implementation decisions may leak through, but you’ll get better at avoiding this over time. If you're truly doing interface decisions without leaking implementation decisions then your test is probably doing something like using playwright to follow a user story or calling a REST API and seeing what comes back. In which case, it probably isn't providing software design feedback, as described in the previous blog post: https://tidyfirst.substack.com/p/tdd-isnt-design https://tidyfirst.substack.com/p/tdd-isnt-design Both blog posts desperately need some examples.