3 ms·

This is a very good article on the same topic by DHH. A great read if you haven't read it before: > Test-first fundamentalism is like abstinence-only sex ed: A

This is a very good article on the same topic by DHH. A great read if you haven't read it before: > Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. https://dhh.dk//2014/tdd-is-dead-long-live-testing.html https://dhh.dk//2014/tdd-is-dead-long-live-testing.html

lancerkind 8y ago
Lol. Absitinence only sex Ed has nothing to do with TDD. Nor is it fundamentalism. It’s a waste of time to ponder as no real conclusions can be made from slapping the fundamentalism label on TDD. Better to just have an open mind and give it a go. And pay attention to the real benefits than to poison your mind against trying something that could help you deliver more features.
Huggernaut 8y ago
To me this is confusing the level of abstraction tests sit with when the tests are written. You can write system tests first and you can write unit tests last, they are orthogonal. I practice double-loop TDD, which involves writing a system level test to drive out some behaviour, then writing other integration or unit tests down through the layers until the system test passes.
- lancerkind 8y ago
  Nice! That’s is the best workflow for me too. Your basically working from big picture downward or said another way: outside in. To do so otherwise creates more risk. I feel the bottom up approach leaves me exposed to discover bad news later in the game and I have to go back and refactor or toss a bunch of code.
- michaelcampbell 8y ago
  This is something I need to try. And concisely stated. Thanks.
- voodootrucker 8y ago
  I've heard this called "outside-in" testing.
  - walligatorrr 8y ago
    I thinks this is more something like ATDD (acceptance test driven development) consisting in capturing specifications in acceptance tests and use them in a second loop to drive traditional TDD. Outside-in TDD or mockist TDD following Martin Fowler’s vocabulary is just a TDD technique extensively using test doubles in order to define how actors collaborate or interact with each other to achieve the specifications.
    - lancerkind 8y ago
      Agreed: * Step 1) (macro) ATDD one or more acceptance criteria * Step 2) (micro) TDD your code to get a macro test to pass.
    - lancerkind 8y ago
      I played a bit with mock driven development (I think this is the same as mockist). I so for haven’t found that valuable other than as a kata for learning a new mocking framework. @walligaotr Have you found mockist useful?
bch 8y ago
This actually says nothing, when you get down to it. The key word is “fundamentalism”, and probably any $foo fundamentalism will satisfy the premise. Take away “fundamentalism” and you’ll see how the “abstinence only” comparison is weak, and the rest does not follow. TDD (w/o the fundamentalism) can be practiced in degrees, and on-and-off, and is not nearly as dogmatic as an abstinence-only sex campaign.
- lancerkind 8y ago
  Agreed. Well said and good points.

lancerkind 8y ago

Lol. Absitinence only sex Ed has nothing to do with TDD. Nor is it fundamentalism. It’s a waste of time to ponder as no real conclusions can be made from slapping the fundamentalism label on TDD. Better to just have an open mind and give it a go. And pay attention to the real benefits than to poison your mind against trying something that could help you deliver more features.

Huggernaut 8y ago

To me this is confusing the level of abstraction tests sit with when the tests are written. You can write system tests first and you can write unit tests last, they are orthogonal. I practice double-loop TDD, which involves writing a system level test to drive out some behaviour, then writing other integration or unit tests down through the layers until the system test passes.

lancerkind 8y ago
Nice! That’s is the best workflow for me too. Your basically working from big picture downward or said another way: outside in. To do so otherwise creates more risk. I feel the bottom up approach leaves me exposed to discover bad news later in the game and I have to go back and refactor or toss a bunch of code.
michaelcampbell 8y ago
This is something I need to try. And concisely stated. Thanks.
voodootrucker 8y ago
I've heard this called "outside-in" testing.
- walligatorrr 8y ago
  I thinks this is more something like ATDD (acceptance test driven development) consisting in capturing specifications in acceptance tests and use them in a second loop to drive traditional TDD. Outside-in TDD or mockist TDD following Martin Fowler’s vocabulary is just a TDD technique extensively using test doubles in order to define how actors collaborate or interact with each other to achieve the specifications.
  - lancerkind 8y ago
    Agreed: * Step 1) (macro) ATDD one or more acceptance criteria * Step 2) (micro) TDD your code to get a macro test to pass.
  - lancerkind 8y ago
    I played a bit with mock driven development (I think this is the same as mockist). I so for haven’t found that valuable other than as a kata for learning a new mocking framework. @walligaotr Have you found mockist useful?

bch 8y ago

This actually says nothing, when you get down to it. The key word is “fundamentalism”, and probably any $foo fundamentalism will satisfy the premise. Take away “fundamentalism” and you’ll see how the “abstinence only” comparison is weak, and the rest does not follow. TDD (w/o the fundamentalism) can be practiced in degrees, and on-and-off, and is not nearly as dogmatic as an abstinence-only sex campaign.

lancerkind 8y ago
Agreed. Well said and good points.