Indeed this will work! I was unsure whether you could fail() a test
inside tearDown() but it seems to work fine -- I just tested it.
Only downside is a mass replacement of all "extends TestCase" with
"extends LuceneTestCase" (but that's a one time cost, now), and making
sure tearDown() always calls super.tearDown().
OK I like this solution better; I plan to go with that. I'll open a
separate issue for it. Thanks Erik :)
Mike
"Erik Hatcher" <[EMAIL PROTECTED]> wrote:
> Mike,
>
> Would it work to have a common LuceneTestCase base class that could
> do that check and fail() in tearDown?
>
> Erik
>
>
> On Oct 4, 2007, at 5:31 AM, Michael McCandless wrote:
>
> >
> > OK, I think I found one possibility here. With ant's junit task, you
> > can define a custom formatter implementing this interface:
> >
> > org.apache.tools.ant.taskdefs.optional.junit.JUnitResultFormatter
> >
> > That interface has a method endTestSuite that is invoked once at the
> > end of all the test cases. So I can define a customer formatter, and
> > in this method, I can check with ConcurrentMergeScheduler and if any
> > unhandled exceptions has occurred, I can throw an exception and the
> > suite/testcase is marked as failed. It seems to work.
> >
> > This is a nice solution in that we don't have to modify every unit
> > test to do its own checking. However, it's not really a "normal" use
> > case because formatters are supposed to just "format" the test result
> > output. It also adds a dependence from Lucene's unit test sources to
> > ant. But at least it does work ("progress not perfection").
> >
> > And objections to this approach? Is there a better approach?
> >
> > Mike
> >
> > "Michael McCandless" <[EMAIL PROTECTED]> wrote:
> >>
> >> "Chris Hostetter" <[EMAIL PROTECTED]> wrote:
> >>>
> >>> : But it'd be nice to do this across the board, ie, for any junit
> >>> test
> >>> : if one of CMS's threads (or, threads launched elsewhere) hits an
> >>> : unhandled exception, fail the testcase that's currently running.
> >>> : I'll dig and see if there's some central way to do this with
> >>> junit...
> >>>
> >>> FYI: i did some casual investigation of this and the only thing that
> >>> jumped out at me is the static
> >>> Thread.setDefaultUncaughtExceptionHandler(...) added in 1.5. for
> >>> 1.4
> >>> there doesn't seem to be a generic way to notice an uncaught
> >>> exception
> >>> from any thread.
> >>
> >> Thanks Hoss.
> >>
> >> Catching the exception is actually not the hard part because I "own"
> >> all the threads spawned by ConcurrentMergeScheduler. What's
> >> tricky is
> >> finding a way to force the currently running JUnit testcase or suite
> >> to fail. I'm digging through JUnit and ant's JUnitTestRunner sources
> >> to see if there's some hook somewhere where we could insert a check,
> >> just before the suite finishes, to assert that no exceptions were
> >> hit.
> >> Or, if I can somehow "look up" the current Test that's running, I
> >> could add an error to it.
> >>
> >> If there are any JUnit and ant experts out there (I'm not!) please
> >> chime in!
> >>
> >> Mike
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
