[Rspec-devel] commit protocol

aslak hellesoy aslak.hellesoy at gmail.com
Sat Jul 22 10:26:47 EDT 2006

On 7/22/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 7/22/06, David Astels <dastels at daveastels.com> wrote:
> > On 21-Jul-06, at 6:48 PM, David Chelimsky wrote:
> >
> > > On 7/21/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > >
> > > OK - not so briliant.
> > > Coverage: 96.0% (threshold: 96.3%)
> > > rake aborted!
> > > Coverage must be at least 96.3% but was 96.0%
> >
> > IMO failing the build due to a coverage # is a bad idea.
> >
> > David's mentioned this earlier... it should give a warning.  Coverage
> > is not a reason to fail the build and prevent a gem from being built.
> What about a hybrid approach where we warn if it drops, but we fail if
> it gets below a team-agreed threshold like 90%?

You won't see a warning. It will fly by in the middle of the build.
And things will deteriorate without anyone noticing. Regressions
should be dealt with when they occur. Dealing with it is easy, as you
will see below.

In fact, I prefer to have the build break if it is not EQUAL to the
current threshold. Then you have three choices:

1) The actual coverage was higher than the current threshold. You
increase the threshold. (Without a build failure you'll forget to do

2) The actual coverage was lower than the current threshold because of
sloppiness. You write more tests until it's back to where it was.

3) The actual coverage was lower than the current threshold because
you wrote some code that is too hard to test. You lower the threshold
to your current coverage.

I have been using this on several ThoughtWorks projects and it works well.


> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel

More information about the Rspec-devel mailing list