Treat code like prose
Love this explanation of refactoring by Michael O McCracken.
From J.B Rainsberger.
Listening to your tests
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.
Using Factories for Rails Fixtures and Test Doubles
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.
RUBY:
-
module FixtureFactory
-
def create_user(attributes = {})
-
User.create!(ModelAttributes.user(attributes))
-
end
-
end
We'll have a Factory for test doubles too.
RUBY:
-
module MockFactory
-
def mock_user(method_stubs = {})
-
mock_model(User, ModelAttributes.user(method_stubs))
-
end
-
end
And the attributes for this model will be declared in a module that's used by both Factories
RUBY:
-
module ModelAttributes
-
def self.user(attributes)
-
attributes.reverse_merge({:name => 'doug'})
-
end
-
end
The Factory modules are then included in Spec::Runnner
RUBY:
-
Spec::Runner.configure do |config|
-
include FixtureFactory
-
include MockFactory
-
end
The objects can now be created using the factory methods available to all specifications.
RUBY:
-
doug = create_user
-
doppelganger = mock_user
Update
Added links to Chris Wanstrath and Daniel Manges' articles on managing Rails fixtures.
Behaviour Driven Development with RSpec slides
Here's my slides for the talk on Behaviour Driven Development and RSpec at the July 2007 singapore.rb meeting. It might not make much sense if you weren't at the meeting.