lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <>
Subject being a good citizen is hard when you can't successfully run tests....
Date Sun, 16 Sep 2012 14:54:54 GMT
Unit tests are good. We all know that. But I'm becoming increasingly
frustrated at trying to run them. I've been working on LUCENE-4326 for
a while (ok, intermittently, but...). I've been almost unable to
successfully run "ant test" at the top level, I'm back to the message:

HEARTBEAT J1: 2012-09-16T10:19:32, no events in:  183s, approx. at:

going on forever, or at least 1,800+ seconds and counting right now. I
have no clue what it means to terminate the test run at this point.
Are there tests that haven't been run yet that won't get run if I
ctrl-C? I don't know....

OK, I can wait for a long time and hope it terminates sometime, which
it has in the past. Eventually. Maybe. Which makes trying to actually
_use_ the tests frustrating at best and I would guess intimidating as
hell for people who do even less coding than I do...

I can terminate the tests and grep for "reproduce with" or "FAILURE"
in the output file. I can run any failing tests on an unaltered branch
(which may well miss stuff if the tests terminate without
completing).... I can do a lot of things that involve checking in code
without successfully doing what it says on the "how to contribute"
page. I see a build target "jenkins-hourly" that seems promising, is
it enough? If so, I'll change the "how to contribute" page....

So what's the story? Given the pace that fixes flow into the system,
others aren't having the trouble I'm having or no new code would get
checked in. So I've got to assume there's a process that's not
documented that people are using in order to make progress. If there
is such a process, we need to make it plain on the "How to contribute"
page, not have it be something that each of us has to create our own
private way of coping. Or fix the system so this doesn't happen all
the time (Yeah, I know, I should feel free <G>).

I'm about to adopt the policy that I'll run any failing tests on the
code on an unaltered tree and if they fail on the unaltered tree I'll
check stuff in anyway. That's poor policy at best, and on the way to
"the hell with the testing" as an attitude. Testing is getting in the
way of progress in my case, not helping me not break things.

Or my particular system (OS x, Lion) is just screwed up and I've been
too lazy to dig enough to understand why...


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message