I feel like if I were to take program design as being the Wikipedia definition: "...the process by which an agent creates a specification of a software artifact, intended to accomplish goals, using a set of primitive components and subject to constraints.[1]", then I can't see your article saying much about that. Instead, the article points to good things about code created using TDD methodologies. Those code-qualities (coupling, etc) may indeed happen with TDD and may be desirable but that seems distinct from the issue of how-to-design or how TDD is design (one assumes the tests are the artifacts but the point is that details need filling-in).

As far I've seen, the "designing by writing tests" approach, mostly succeeds in the web-apps field where one has an implicit/assumed CRUD/MVC structure, writes tests for behavior and filling in functions based on this assumed structure.

I haven't seen anything about how one proceeds with TDD if one has the more complex task of implementing an algorithm, a language or something with highly structured requirement. I'd be interested in how one would do that.

[1] https://en.wikipedia.org/wiki/Software_design

I don't think this wiki page is intended to show specific examples. But here's one I really like that isn't a typical MVC web app: https://www.youtube.com/watch?v=XHnuMjah6ps

The process he's using there falls in line with the higher-level experiences described on the wiki.

Great article. I'm working in a talk about Developer Flow and TDD and towards finding that elusive zen like state where the TDD you are practicing helps really drive out the design and strongly guides what to code next, and next and next. Specifically that TDD can be used to find this nice developer rythm.

Has anyone had this experience/success with this? What can help make the difference towards getting that nice flow out of TDD.

I'm inspired by Corey Haines and a bunch of code experiments he's illustrated over the years. One technique that struck me was that a nil return from a method was was an expected and desirable step during a TDD cycle and that guard clauses can be very helpful to driving out TDD designs while maintaining flow.

I'm looking for similar patterns for TDD decision making, especially those that help the dev stay in a good rythm.

Would love any ideas towards exploring this further.

The steps he describes for the London School of TDD help me get into that flow: https://github.com/testdouble/contributing-tests/wiki/London...

Do you need help? I'm completely on board for that mission and personally feel that we as an industry do a really bad job at testing past the evangelizing phase. Teaching people how to actually test code is something I think we need to do better.

Do you need help? I'm completely on board for that mission and personally feel that we as an industry do a really bad job at testing past the evangelizing phase. Teaching people how to actually test code is something I think we need to do better.