Hi Robert,

Thanks for commenting on the chapter about starting from the test! I appreciate your opinion!

I agree that starting backwards is a little less practiced technique from among those I described, especially among the fluent TDD practitioners. I often use it though when I show TDD to someone else who is not familiar with it. This is because people are having a hard time starting from test and thinking about the end result is sometimes easier than declaring an object and all its collaborators upfront. This is especially true when using mocks - novices often don't know what to mock, what not, but it's fairly straightforward to say "ok, let's say I want the alarm triggered..." and work from that.

When starting from test, it's always easier to go from "knowns" to "unknowns". So when I already have an object and I know what method is yet to be implemented, I often start from that and then wonder "so what is really expected by someone who invokes this method?". When the API is not yet known, concentrating on end result lets me play around with shaping the API, while still concentrated on the end result (this is especially true with few initial tests in a codebase).

Another thing I appreciate is that it often produces more readable variable names. When my assertion goes last, I often have the temptation to write:

Assert.Equal(0, result);

while when starting from assertion (or mock verification), I tend to name the result variable(s) better, e.g.

Assert.Equal(0, arrayElementCount);

Anyway, "starting from the end" is just one of the techniques. In my opinion, It's useful to familiarize with them all and pick one that best suits current situation or your flow of thinking in a given moment.

P.S. Just want to mention that I don't claim any credit for inventing this technique - I got it from Kent Beck's book :-).

Hi Grzegorz,

Thanks for the great comment! I completely agree with everything you said. As I hinted in the post - I think it's a really great technique that I'm sure I would find useful in some scenarios where I don't have a clue what I'm testing and certainly is a useful technique for people getting started.

One alternative is the nested classes approach to writing unit tests

Cool. I like that.

When I finish the next post in the series I'll be covering something that is similar, but that is still a little different in intent so is a handy link.

Thanks mate