

Responsibility Driven Design with Mock Objects - edw519
http://www.methodsandtools.com/archive/archive.php?id=90

======
noss
This is a very interesting read with regard to unit testing.

I'll have to read it again a few times more so I don't miss out on any good
conclusions.

------
chrismear
Oh man, another '.DD'. I don't think I've even figured out the difference
between BDD and TDD yet.

~~~
noss
Isn't that one simply that BDD is about testing the functionality independent
of how it is implemented, making BDD good for acceptance tests. And TDD is
more about testing parts of an implementation to see that it does the right
thing to implement the functionality, making TDD good for keeping on the path
while implementing.

But yeah. Terminology within testing is quite messy. Some things are
overlapping, different groups have different names for the same thing, and
different groups have the same name but for different things.

~~~
chrismear
Maybe this is the issue -- I've seen these things explained the other way
around.

My experience is in Ruby (specifically Rails), with Test::Unit (usually used
to espouse TDD), and RSpec (recommended for BDD-style development).

With TDD, I follow the pattern of using real objects for almost everything
(only mocking out API wrappers, etc.), setting some initial values, poking a
method, and then testing that some final values are as they should be.

With BDD, I end up mocking and stubbing almost everything, and then writing a
test that checks that my object under test calls the right methods on other
objects.

I like the BDD school for its focus on testing one class in isolation, but
often when writing BDD-style tests I just end up echoing the (eventual)
implementation in test-form, line by line. It's entirely possible I've got
utterly the wrong end of the stick, but I can't shake the feeling that it
seems a bit redundant at best, and of little added value at worst.

