[rspec-users] Spec'ing via features

Matt Wynne matt at mattwynne.net
Mon Nov 24 11:34:35 EST 2008

On 21 Nov 2008, at 18:15, James Byrne wrote:

> As I work with Rails TestUnit tests I am reconsidering how to use
> cucumber features.  It seems to me that it might be best to have a
> coherent view of how to arrange my test suites before I get much  
> further
> into this.  Now, so far I have considered three possibilities:
> 1. Use features exclusively. Create a feature file for each model, one
> for each controller and possibly an additional one for those views  
> that
> need separate tests.  Name then with the nomenclature x_model.feature,
> x_model_controller.feature and where desired, x_view.feature
> 2. Use features exclusively. Create one feature file for each
> non-decomposable piece of system functionality.  Test models,
> controllers and views within each feature file.
> 3. Use features and RSpec.  Well, is that not what I am doing with
> features alone?  Or, are their cases when testing with RSpec spec  
> files
> are a better choice than a features scenario?
> 4. Use features and TestUnit. Naaahhh...
> 5. Some other way of which I have not considered.
> In the interest of enlightenment and from a desire to avoid  
> unnecessary
> back tracking as my project develops, what do experienced  
> practitioners
> suggest as the favoured way of arranging test suites.
> Yes, I have done the goggle thing but I really have not found anything
> terribly useful about organizing tests specifically for Rails.

No doubt it's (3) for me. It's all about working from the outside in.

Cucumber is for Acceptance Testing, and those acceptance tests should  
not be cluttered up with edge cases. They should ideally be readable  
by your stakeholders / customers.

Equally, when you hit something complicated in a class that's likely  
to be pulled in different directions by different features, it's  
responsible to start writing unit tests for it. Whether you choose to  
use RSpec or Test::Unit for those unit tests is really up to you.  
Those unit tests can then be used by the next programmer who comes  
along to change that class to satisfy another feature as well as yours.

I am absolutely loving doing BDD from the outside in. Driving early  
changes from Cucumber acceptance tests means you have so much more  
space within which to refactor (not being hemmed in my unit tests /  
mocks) as the design emerges during those first few iterations. It's  
been nothing short of a revelation for me.


More information about the rspec-users mailing list