[rspec-users] Spec run heuristics (Re: Cucover: coverage-aware 'lazy' cucumber runs)
ashley.moran at patchspace.co.uk
Sat Apr 11 14:02:01 EDT 2009
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? 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>
More information about the rspec-users