4 ms·

I'm the author of that article and if anyone has any questions, feel free to ask me. I'm building up the wiki of well-discussed but rarely documented nuances to

by searls 11y ago

I'm the author of that article and if anyone has any questions, feel free to ask me. I'm building up the wiki of well-discussed but rarely documented nuances to testing that I think are worth capturing. A lot of these little articles are things I've discussed a dozen times over six years with people close to the "movement", but still aren't even google-able. The reason I think this is important is that ideas about TDD people had from 2000-2007 still has a profound impact on testing tools and practices more broadly. For example, very very few developers I meet know how to apply test doubles rigorously and what their purpose is. This might help that.

joe_the_user 11y ago
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 https://en.wikipedia.org/wiki/Software_design
- blaix 11y ago
  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 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.
benihana 11y ago
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.
bucky 11y ago
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.
evolve2k 11y ago
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.
- blaix 11y ago
  The steps he describes for the London School of TDD help me get into that flow: https://github.com/testdouble/contributing-tests/wiki/London-school-TDD#what-is-it https://github.com/testdouble/contributing-tests/wiki/London...

by searls 11y ago

joe_the_user 11y ago

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 https://en.wikipedia.org/wiki/Software_design

blaix 11y ago
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 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.

benihana 11y ago

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.

bucky 11y ago

evolve2k 11y ago

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.

blaix 11y ago
The steps he describes for the London School of TDD help me get into that flow: https://github.com/testdouble/contributing-tests/wiki/London-school-TDD#what-is-it https://github.com/testdouble/contributing-tests/wiki/London...