Putting it together

by Luismi Cavallé

We already knew that there were two styles of testing: state-based and interaction-based. The former consists of specifying how the state of an object should change after exercising its methods. As for the latter, the interaction between the object and its collaborators is what is specified. Martin Fowler distinguishes between the users of each style as classicists (state-based) and mockists (interaction-based), because of the tool needed to perform this style of testing, known as mocks.

Similarly to mocking, which is a technique that enables a style of testing different to the classical, we could begin to talk of a testing style made possible by the use of macros and call it *structure-based testing*.

I’ve already blogged about Shoulda and its macros, but given the recent news about the Shoulda - RSpec love affair and the remarkable increasing popularity of Shoulda-like macros, I reckon it’s time to revisit the subject.

I find appropriate to call this style of testing structure-based because it doesn’t involve the interactions nor the changes of the state, but the actual structure of the object under test. In that sense, structure means the opposite of behaviour. These tests don’t say anything about the behaviour of the object, just what it should look like.

describe User do                             # class User < ActiveRecord::Base
  it { should belong_to(:account) }          #   belongs_to :account          
  it { should have_many(:posts) }            #   have_many :posts             
  it { should validate_presence_of(:email) } #   validate_presence_of :email  
end                                          # end

The thing is, I think there’s hardly any value in this kind of testing. Obviously these tests are easy to write and quick to run. The cost of writing them is low so the benefit could also be low and still be a good investment. However, there is usually an almost exact correspondence between the spec and the implementation. It would be possible to automatically generate one from the other. I can see some remote value in thinking twice about the structure of the object, but that won’t give me any clue about whether that structure will provide the behaviour I need to implement the current functionality. I’m just writing the same thing twice, but with different languages.

Satisfaction Guaranteed

Unit-testing Rails applications is not straightforward. Dan North justifies this by blaming the framework itself and the coupled nature of its components. Shoulda macros gives you a shortcut, they “make tests easy on the fingers and eyes”, that’s the framework’s motto. And they certainly provide what they promise: instant gratification, effortless testing with high code coverage and relatively fast execution time you can perform “all the fucking time”, like the cool kids do. The question is, does it provide any real value to the development process?

The answer depends, of course. It depends on each developer, team and context. My current approach of Rails testing is pretty different. But that might very well change in the future. The success probably lies in continuously challenging the why and the how of the way you do things, keeping in mind that there is no silver bullet and that, ultimately, it’s all about effectively building software that provides value to someone.