3 ms·

Canon TDD

4 points by cratermoon 3y ago

xnorswap 3y ago
My criticism of this and similar articles is that in this article we're back in the mythical Widget factory where programmers are given requirements to create or improve widgets. In my real world experience, the largest amount of work necessary to work in this manner is in step 1 and 2, where the business requirements need nailing down. But this is also where business stakeholders disappear. It's better or worse at different companies, and what I'll highlight here is the worst case, but even in the best places this still happens to a lesser degree: Once the story is written, stakeholders become uninterested, they consider further design is an implementation detail and not their job, they become "busy" when you try to ask questions. This is work that overall the business doesn't prioritise and doesn't properly give everyone time to do, so stakeholders dodge their responsibility (or don't realise it is their responsibility) and developers are left to make things up. But a developer left to their own devices will often think of the implementation designs first, and then think about the tests. The more experienced developers will keep edge cases in mind, but they are still edge cases relating to the design, not the interface. To have an entire process around iterating around the edges, is something it's difficult to convince people the value of. So you come away from an article like this feeling warm and fuzzy but any attempts to implement such a process crumbles against hard reality. And then the author dismisses such criticism by saying "well that's not TDD". Well sure, he coined the term, so he can choose to define it, but it's not helpful for anyone looking to practice TDD if everything they try gets dismissed by a No True Scotsman argument.
MoreQARespect 3y ago
>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.
- cratermoon 3y ago
  > Both blog posts desperately need some examples. There's an entire book by the author, titled Test-Driven Development by Example. I bet you can find a library to lend you a copy. <https://search.worldcat.org/title/50479239 https://search.worldcat.org/title/50479239>
  - MoreQARespect 3y ago
    Im good thanks. Im not the one complaining that the author's blog posts are being misinterpreted.

4 points by cratermoon 3y ago

My criticism of this and similar articles is that in this article we're back in the mythical Widget factory where programmers are given requirements to create or improve widgets. In my real world experience, the largest amount of work necessary to work in this manner is in step 1 and 2, where the business requirements need nailing down. But this is also where business stakeholders disappear. It's better or worse at different companies, and what I'll highlight here is the worst case, but even in the best places this still happens to a lesser degree: Once the story is written, stakeholders become uninterested, they consider further design is an implementation detail and not their job, they become "busy" when you try to ask questions. This is work that overall the business doesn't prioritise and doesn't properly give everyone time to do, so stakeholders dodge their responsibility (or don't realise it is their responsibility) and developers are left to make things up. But a developer left to their own devices will often think of the implementation designs first, and then think about the tests. The more experienced developers will keep edge cases in mind, but they are still edge cases relating to the design, not the interface. To have an entire process around iterating around the edges, is something it's difficult to convince people the value of. So you come away from an article like this feeling warm and fuzzy but any attempts to implement such a process crumbles against hard reality. And then the author dismisses such criticism by saying "well that's not TDD". Well sure, he coined the term, so he can choose to define it, but it's not helpful for anyone looking to practice TDD if everything they try gets dismissed by a No True Scotsman argument.

MoreQARespect 3y ago

>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.

cratermoon 3y ago
> Both blog posts desperately need some examples. There's an entire book by the author, titled Test-Driven Development by Example. I bet you can find a library to lend you a copy. <https://search.worldcat.org/title/50479239 https://search.worldcat.org/title/50479239>
- MoreQARespect 3y ago
  Im good thanks. Im not the one complaining that the author's blog posts are being misinterpreted.