[rspec-users] Spec run heuristics (Re: Cucover: coverage-aware 'lazy' cucumber runs)

[Ashley Moran]

On 10 Apr 2009, at 02:12, Matt Wynne wrote:
> What does it mean for Cucumber to be lazy? It will only run a  
> feature if it needs to.

While I have yet to do more than skim the full articles, I wondered if  
you'd seen "Integration Tests Are A Scam" on InfoQ[1]?  It was the  
following that caught my attention:

> the hypothetical programmers with the integration-based test suite  
> choose to worry only about "the most important [x]% of the tests"

Towards the end of the second article he seems to say it's more  
excessive integration testing that is the problem.  (Even if he does  
end with "Stop writing them.")  Strikes as me as rather along the  
lines of, albeit in the opposite direction to, "we don't mock because  
it makes the tests fragile".

I was just idly thinking, could a code-coverage based system could be  
combined with some sort of failure (fragility) history to balance the  
time cost of heavy feature runs with the benefits of having something  
run end-to-end?  We've had reverse-modification-time spec ordering for  
ages which is a useful start.

On a more ranty note - I have very little time for these "XXX BDD/ 
development technique is always bad, don't do it" articles.  (But hey,  
maybe I was guilty of this myself and have forgotten since...)  Pretty  
much every technique I've seen has some benefit - if you use it  
selectively.  I wish people would stop writing these inflammatory  
articles, and (a) figure out how to use these techniques like razors  
not shotguns and (b) go and improve the tools that apply them.   
Otherwise they're just making everyone's life harder.  Gah!!!  </rant>

Ashley

[1] http://www.infoq.com/news/2009/04/jbrains-integration-test-scam

-- 
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
http://aviewfromafar.net/
http://twitter.com/ashleymoran