On 2 Dec 2008, at 14:11, Peter Jaros wrote:
On Mon, Dec 1, 2008 at 2:50 AM, Matt Wynne <[EMAIL PROTECTED]> wrote:
I've been thinking about a more sophisticated mechanism for this,
using code
coverage. If autotest / rspactor was able to record and remember
the LOC
covered by each scenario / example, it would be possible to do more
focussed
regression testing when a source file was changed.
It's a clever thought, but you don't know about code which scenarios
*will* depend on in the future. You'd have to manually restart
autotest and have it recalculate all of the mappings.
Well. I reckon I would be adding new code under two circumstances:
(1) I am refactoring existing code, sprouting out classes etc.
(2) I am cutting new code to pass a new, failing, scenario / spec
In case (1 - refactoring), I expect that as I move code out of
BigFatClass and create ShinyNewClass, I would have to save
big_fat_class.rb, which would trigger the tests that cover it. That
would then update the coverage mappings to also cover shiny_new_class.rb
In case (2 - adding new code, guided by tests), there would be failing
tests to re-run which, when run, would hopefully spin up the new code
as I write it. The re-run of failing tests could be triggered either
manually, or by a trigger that just watched the folders where new
source files were likely to crop up.
WDYT? Possible?
Matt Wynne
http://blog.mattwynne.net
http://www.songkick.com
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
