What would you prefer, TestDD or BugDD ?

The Cost of Test Driven Development

Bug Driven Development


… Put simply there is a difference between Mock and Stub objects and RhinoMocks recognizes that allowing us to write tests that better state their purpose.

Mock objects are used to define expectations i.e: In this scenario I expect method A() to be called with such and such parameters. Mocks record and verify such expectations.

Stubs, on the other hand have a different purpose: they do not record or verify expectations, but rather allow us to “replace” the behavior, state of the “fake”object in order to utilize a test scenario …


Unit testing with Mock objects (Rhino Mocks)


“What are the definitions of Dummy, Fake, Stub, and Mock objects?
Meszaros uses the term Test Double as the generic term for any kind of pretend object used in place of a real object for testing purposes. The name comes from the notion of a Stunt Double in movies. (One of his aims was to avoid using any name that was already widely used.) Meszaros then defined four particular kinds of double:
Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).
Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it ‘sent’, or maybe only how many messages it ‘sent’.
Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.
To put it in my own words: mock objects “expect” certain methods to be called on them, and typically cause a unit test to fail if their expectations aren’t met. Stub objects provide canned responses (and can be autogenerated by helper libraries), but typically do not directly cause the unit test to fail. They are typically just used so that the object you’re testing gets the data it needs to do its work.”

Mocks Aren’t Stubs
“The term ‘Mock Objects’ has become a popular one to describe special case objects that mimic real objects for testing. Most language environments now have frameworks that make it easy to create mock objects. What’s often not realized, however, is that mock objects are but one form of special case test object, one that enables a different style of testing. In this article I’ll explain how mock objects work, how they encourage testing based on behavior verification, and how the community around them uses them to develop a different style of testing.”
“… both styles accuse the other of being too much work. Mockists say that creating the fixtures is a lot of effort, but classicists say that this is reused but you have to create mocks with every test.”


Classical vs Mockist testing


Rails Conf 2013 The Magic Tricks of Testing by Sandi Metz


“Tell-Don’t-Ask is a principle that helps people remember that object-orientation is about bundling data with the functions that operate on that data. It reminds us that rather than asking an object for data and acting on that data, we should instead tell an object what to do. This encourages to move behavior into an object to go with the data.”

“Procedural code gets information then makes decisions. Object-oriented code tells objects to do things. — Alec Sharp”