Hacker News Reader

Comment by Huggernaut | Hacker News Reader

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.

View on HN

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.

This is something I need to try. And concisely stated. Thanks.

I've heard this called "outside-in" testing.

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.

Agreed: * Step 1) (macro) ATDD one or more acceptance criteria * Step 2) (micro) TDD your code to get a macro test to pass.

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?

Reply on news.ycombinator.com