Specifying raising of errors in RSpec

March 24th, 2008 at 12:20 pm (Behaviour Driven Development, Ruby)

RSpec allows a developer to specify that an error is raised within a block with the raise_error method. It's a nice expressive way of saying that your code should fail when it needs to.

But my tiny brain has often been confused with using it at times, more so when the error class requires parameters for instantiation and when used in conjunction with the and_raise method on a stub or a mock

Consider the snippet below where my Widget depends on Thingamajig to do its funky thing in order to run. But Thingamajig is rigged to explode in a mass of funkyness and make Widget all useless.

PLAIN TEXT
CODE:
  1. describe Widget do
  2. it "should re-raise errors as a Widget::UnrecoverableError" do
  3. # expectations
  4. thingamajig = stub(Thingamajig)
  5. thingamajig.should_receive(:do_funky_thing).and_raise(Thingamajig::FunkyExplosion.new('The funky thang exploded yo'))
  6.  
  7. # our SUT
  8. widget = Widget.new(thingamajig)
  9.  
  10. #verification
  11. lambda { widget.run }.should raise_error(Widget::UnrecoverableError, 'The funky thang exploded yo')
  12. end
  13. end

Do you notice the inconsistency between the way errors are declared in the expectation and the actual verification?

PLAIN TEXT
CODE:
  1. # expectations
  2. thingamajig.should_receive(:do_funky_thing).and_raise(Thingamajig::FunkyThingExplosion.new('The funky thang exploded yo'))
  3.  
  4. #verification
  5. lambda { widget.run }.should raise_error(Widget::UnrecoverableError, 'The funky thang exploded yo')

The expectation on the stub, 'thingmajig' needs the exception instantiated first while verification requires the class name and parameters used to instantiate the error instance.

And no, doing it like this doesn't work as expected:

PLAIN TEXT
CODE:
  1. lambda { widget.run }.should raise_error(Widget::UnrecoverableError.new('The funky thang exploded yo'))

It's an unfortunate impedance mismatch that might be caused due to the way Ruby handles the raising of errors.

Comments

Behaviour Driven Development != Testing

December 23rd, 2007 at 12:59 pm (Behaviour Driven Development)

Testing: Executing a program with the specific intent of uncovering errors.

Software Engineering: A Practitioner's Approach - Roger S Pressman

The definition of testing by Pressman states that the purpose of performing software testing is to detect errors in a program. This encompasses a wide range of techniques such as black box/white box testing, basis path testing, fault based testing and at a more thorough level, control structure testing.

So where do the specifications in Behaviour Driven Development (BDD) fit into the picture? In this respect, BDD isn't about testing at all. We write specifications to say that the software exhibits a specific behaviour when its in a certain state. The specifications serve to reinforce the notion that the program is working as expected under known conditions.

Having 100% coverage for code certainly does not mean that a program is free of errors, there are still edge cases that may be too difficult or complex to replicate with an automated test suite. Traditional QA testing is still very much relevant to software projects with BDD employed religiously throughout development.

This has been discussed at length before but it bears repeating: BDD is a design technique that gives you executable documentation of what functions the software is expected to provide.

Comments

Listening to your tests

August 26th, 2007 at 1:29 pm (Behaviour Driven Development)

One of the challenges I've been trying to overcome in practicing Test First Development(TFD) has been making sense of the feedback that comes from TFD. It was not obvious to me till recently, after I've read an excellent article (IEEE Explorer account required) by Bas Vodde and Lasse Koskela in IEEE Software. Bas and Lasse recount their experiences in conducting TFD workshops in Nokia and in particular the insights gleaned from a TFD coding exercise.

One key point made by the authors was that although the participants in the coding exercise followed the test-code-refactor cycle, their code became progressively complex and littered with nested branching constructs. It made keeping track of the software's behaviour difficult. Bas and Lasse observed that once the the initial design approach was chosen, none of the participants thought about whether the design was still suitable for the current requirements.

Essentially, the test-code-refactor cycle was taking longer to complete and the code was turning out to be an unmaintainable mess. This feedback was lost on the participants and while some decided to hide the code's complexity behind refactorings that make the code read better, others simply added more tests and attempted to make them pass.

It should be obvious that emergent design will only occur when there is constant reflective thinking about the state of the code. This takes a bit of skill and confidence on the part of the developer. Simply going through the motions of test-code-refactor to the simplest design without this reflective thinking will lower the effectiveness of TFD as a design technique.

1 Comment

Using Factories for Rails Fixtures and Test Doubles

August 11th, 2007 at 12:54 pm (Behaviour Driven Development, Rails, Ruby)

Chris Wanstrath has written about making Rails fixtures less painful than they need to be with the FixtureScenarios plugin. Personally, I prefer the Factory approach, nicely explained by Daniel Manges.

I've been using factory methods to create in-database ActiveRecord objects for a project that I've been working on in Bezurk. Reading Daniel's article gave me a few ideas on improving the way I create fixtures and mocks. Since I've been using RSpec extensively in this project, I'll present the examples in RSpec.

As the models evolve with the design and its behaviour change accordingly, there is a need to go through all the specifications that create this model and make sure that its created in a valid state. This is more pronounced with the use of test doubles, the test doubles also need to have its method stubs changed to reflect the latest state of the model that its is representing. I happen to make much use of test doubles for test isolation, so trying to manage all these objects became an exercise in patience. As it was getting painful, It's time to change the way I create these models and test doubles.

As always, a layer of indirection will always go some way to solving a software problem. We introduce a Factory that encapsulates the creation of ActiveRecord objects by providing creation methods.

PLAIN TEXT
RUBY:
  1. module FixtureFactory
  2. def create_user(attributes = {})
  3. User.create!(ModelAttributes.user(attributes))
  4. end
  5. end

We'll have a Factory for test doubles too.

PLAIN TEXT
RUBY:
  1. module MockFactory
  2. def mock_user(method_stubs = {})
  3. mock_model(User, ModelAttributes.user(method_stubs))
  4. end
  5. end

And the attributes for this model will be declared in a module that's used by both Factories

PLAIN TEXT
RUBY:
  1. module ModelAttributes
  2. def self.user(attributes)
  3. attributes.reverse_merge({:name => 'doug'})
  4. end
  5. end

The Factory modules are then included in Spec::Runnner

PLAIN TEXT
RUBY:
  1. Spec::Runner.configure do |config|
  2. include FixtureFactory
  3. include MockFactory
  4. end

The objects can now be created using the factory methods available to all specifications.

PLAIN TEXT
RUBY:
  1. doug = create_user
  2. doppelganger = mock_user

Update
Added links to Chris Wanstrath and Daniel Manges' articles on managing Rails fixtures.

Comments