lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven A Rowe <sar...@syr.edu>
Subject RE: being a good citizen is hard when you can't successfully run tests....
Date Sun, 16 Sep 2012 18:26:25 GMT
I always run both Lucene and Solr tests.  Yes, Solr tests are more likely to fail than Lucene
tests.  When that happens, I see if I can repro with the same seed (almost never works), then
run the remaining modules' tests.

Related question: how hard would it be to set up Ant testing to be like the maven --fail-at-end
test option?  That way at least when failures do occur, they wouldn't block other testing.

Steve

-----Original Message-----
From: Uwe Schindler [mailto:uwe@thetaphi.de] 
Sent: Sunday, September 16, 2012 11:45 AM
To: dev@lucene.apache.org
Subject: RE: being a good citizen is hard when you can't successfully run tests....

I generally never run Solr tests. When I changed smthg in Lucene, I just run ant validate
(not precommit) to see if it compiles and let the rest does Jenkins. I am tired of waiting
for Solr tests, they are sometimes passing sometimes not, sometimes take hours or sometimes
obviously also drink my beer when I am away from my computer.

Uwe

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de

> -----Original Message-----
> From: Erick Erickson [mailto:erickerickson@gmail.com]
> Sent: Sunday, September 16, 2012 4:55 PM
> To: dev@lucene.apache.org
> Subject: being a good citizen is hard when you can't successfully run tests....
> 
> 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:
> TestReplicationHandler.test
> 
> 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...
> 
> Erick@FrustratedOnASundayMorning
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Mime
View raw message