On Tue, Nov 25, 2008 at 20:35, Neels J Hofmeyr <neels_at_elego.de> wrote:
> Greg Stein wrote:
>...
>> Could I suggest to keep the branches to "zero test failure" like the
>> trunk? That when a failure happens, to stop work and fix it?
>
> But I'm not running tests all the time... I'm wondering how you guys out
> there handle the tests. Do you run make check or only selected parts of the
> test suite, how often do you run it, how long does it take you to do that
> and how do you evaluate which test failures were actually introduced by you?
I run "make check" on pretty much *all* of my commits. The WC is very
brittle, and a change in one place can have serious consequences
elsewhere. And many times, with no obvious connection. Thus, it is
very important to run the full test suite.
"introduced by you" ... that is an easy answer. If the trunk and
branches are kept at a *zero tolerance* for test breakage, then any
failure was introduced by your changes. Simple as that.
As long as there is a question about "did the checked in code already
have this breakage?" then we're in the shit. When the checked-in code
is always clean, then you *know* that you broke the tests with your
change. So you stop and fix it before committing.
> For me a make check is very time-consuming to pull off. Instead, I run e.g.
> only the update_tests and switch_tests when I worked on update, but that's
> pretty much it.
Fine. Take 30 minutes to run "make check". Think about how much time
you save the next person from wondering whether they broke the test,
and have them investigate how their code could possibly have broken
it... only to find that it *wasn't* their code. That is was something
totally unrelated and crazy impossible to track down since they
weren't anywhere in the codebase near the breakage.
What is your 30 minutes compare to N developers each trying to track
down a failure?
Invariably, there is always some time to run that test. I typically
start the "make check" and then start producing my commit message
while I review my "diff" for my commit. I always produce a diff,
review that, and build a commit message. Lots of times, when reviewing
that diff, I might find some stray debug message, or something a
little better that I could do, or maybe something that I forgot. But
it does take a bit to produce that, and in the background, my test run
is proceeding.
Pause and watch some TV. Surf some web pages. Take a dump. Grab a
beer. Whatever... there is always something to do while waiting for
that test to complete, and it will help your fellow developers
immensely.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-26 06:45:57 CET