Specify exactly what you want to happen and no more

There is a discussion in the spanish TDD group about whether it is good or bad, when you have a stub object, to return a different value depending on the input arguments of the method. I don't think it's the right thing to do because, normally, when a stub object cares about the input arguments in its method calls it's because it should not be a stub object, it should be a mock object. Let me explain it with an example:



The payment gateway is a stub that returns true when user_has_funds is called with an input argument of 50.
If we look carefully at the test, what we are really doing is testing more than one behavior. First, we're asserting that a user can buy stuff if she has sufficient funds. Second, we are expecting that the payment gateway is called with the right amount.
So, if it is an expectation, why don't we use a mock instead of a stub? We're mixing the concepts of mock and stub and, as a consequence, we're testing more than one thing.We're breaking the single responsibility principle.

Steve Freeman and Nat Pryce, authors of the great Growing objects oriented software, guided by tests, recommend to follow a simple rule of thumb, "specify exactly what you want to happen and no more". If we listen to them (and we should!), those are the resulting tests:



The first test specifies the relationship between the order and the payment gateway (The message protocol). It uses a mock object to replace the gateway payment object and it expects a call at user_has_funds method with the order amount as an input argument. We want to know that the payment gateway is going to be called with the right amount, so we are interested in its input argument (which is right when mocking). The second one specifies the behavior of the order when the user has funds, and I don't really care about how the order interacts with the payment gateway. I just want to know that the user has sufficient funds. That's why, in this case, we use a stub.

What I like about the new tests is that, if we change the order behavior by adding some taxes to the product price, the second test is not going to break (we still confirm the order if the payment gateway says that the user has funds, nothing has changed in that specification). Only the first one would be red (and for the right cause, we've changed exactly that specification).

What do you think?

PS: I know that, in RSpec:mocks, stub() is an alias for mock() and I don't like it very much :P

String calculator kata

On Friday, Aimee suggested me that, in order to improve my English, I should write some of my blog entries in that language so, every now and then, I am going to write short entries in English :D

As I have told you before, I need to practice, practice and practice. The problem I have chosen to start with is the string calculator kata. For those of you who do not know this kata, it is a very simple problem. Someone gives you a string with numbers separated by a defined separator and you have to calculate the sum of that numbers. You can find the actual code-kata specification here.

This is not the first time I confront this problem, I already did it some months ago in Java. Now, I am doing it in Ruby and the code I am writing is much more precise than the one in Java. Ruby classes are more friendly than the Java ones (Manipulate Strings in java is a nightmare compared with Ruby), and everything seems simpler. I am not an expert in Ruby nor in Java, but I think Ruby is a much more friendly language to work with.

I will practice this kata every day until I feel ready to record a screencast so, Stay tuned!

Meanwhile, here is the kata done in scheme by Enrique :D

String Calculator Kata from Enrique Comba Riepenhausen on Vimeo.