RSpec — common base specs
Sometimes I am fond of creating inheritance chains for tests, which is easy in Java or C# say, but not quite as obvious in rspec.
Define and register a base class
It just needs to inherit from Spec::Example::ExampleGroup so it’s runnable.
require 'spec/example/example_group' class UnitTest < Spec::Example::ExampleGroup protected def you_can_call_this end end Spec::Example::ExampleGroupFactory.register(:unit_test, UnitTest)
Set the type when describing
describe 'By supplying the :type', :type => :unit_test do
it 'this example group inherits from whatever class you supply as :type' do
self.protected_methods.should include('you_can_call_this')
end
end
You now have common base class to your specifications.
Test driving and test coverage
Yesterday I enabled rcov on my current project and was surprised that it had 100 per cent unit test coverage.
But perhaps I should not have been surprised. After all, if you are truly test driving, how could you possibly leave anything uncovered?
Refactoring Example — Fat Controllers
We have an MVC controller that takes some input from a user, finds a file in a particular MP3 flavour, and then calculates the hash of the MP3 frames in that file.
Here’s what it looked like to begin with (an arrow means depends on):
Mp3HashController |---------------> TrackFileFinder |---------------> StreamHasher |---------------> Log
Operation:
- Take input of trackid and format id (both numbers)
- Open a stream on the file
- Supply that stream to the StreamHasher
- Return the hash as text to user
Next requirement — learning file hashes
This works as required but we can improve performance by reducing the number of times we calculate a file’s hash. Assuming each file is static — i.e., its MP3 frames will never change — then we only need to calculate its hash once.
Rather than do this every time, we could save the result somewhere — a database perhaps. Which means we are introducing new behaviour.
When producing a hash, first check whether it already exists
If it does exist, then return it
Otherwise generate it and store it for next time
We could naively add a new HashRepository collaborator:
Mp3HashController |---------------> TrackFileFinder |---------------> StreamHasher |---------------> Log |---------------> HashRepository
But now our interface is expanding, this has a habit of getting out of control and you can end up with ten constructor arguments. This is commonly known as the “Too Many Dicks on the Dance Floor” problem.
So what’s wrong with it?
- Mp3HashController is no longer composing its behaviour from one layer of abstraction. This notion of learning return values has changed that. It is now exposed to details it shouldn’t have any knowledge of let alone dependency on.
- Mp3HashController is now more difficult to test, there are more paths that have to exercised though the same interface
- There is new conditional behaviour here that clearly belongs on its own — clients should not even know this is happening
- It is much easier to test the learning behaviour on its own — I shouldn’t have to probe a controller
- I shouldn’t have to describe an object’s behaviour in terms of another objects interface, I should be able to use that object directly
- I would likely have to suppress some behaviour(s) while testing others. This will be manifest itself as complicated stubbing
- Lots of dependent stubbing. Each of those collaborators are actually collaborators themselves. I think this is a smell. I shouldn’t have to consider this when unit testing Mp3HashController.
There is an opportunity to introduce an abstraction here. If we consider that all Mp3HashController requires is something to get a hash, then we can actually reduce it to:
Mp3HashController |---------------> Log |---------------> HashRepository
And then we have a HashRepository implementation like this:
LearningHashRepository |---------------> TrackFileFinder |---------------> StreamHasher |---------------> HashRepository
The LearninghHashRepository has the responsibility of storing any hashes that don’t exist.
This could probably be condensed even further. TrackFileFinder and StreamHasher represent the concept of obtaining the hash of a file given a track identifier, so they can be combined. This reduces LearningHashRepository to a sort of write-through cache.
Ben Biddington 