3 ms·
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,
by 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 agoNice! 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 agoThis is something I need to try. And concisely stated. Thanks.
- voodootrucker 8y agoI've heard this called "outside-in" testing.
- walligatorrr 8y agoI 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 agoAgreed: * Step 1) (macro) ATDD one or more acceptance criteria * Step 2) (micro) TDD your code to get a macro test to pass.
- lancerkind 8y agoI 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?