Re: FailureRecorder design issue or bug

[Stefan Bodewig <bo...@apache.org>]

I know its been a long time since you asked this (and I initially hoped
Jan would jump in since FailureRecorder is mostly his baby 8-).

On 2010-03-13, Clark Archer <cl...@gmail.com> wrote:

> During implementing my previously mentioned test history recorder, I
> discovered an issue with the current FailureRecorder implementation.  The
> problem I'm seeing is that it doesn't write the failure suite Java class
> when the JUnitTask forks a new JVM to execute tests.

Jumping straight to the end of your mail, I'd consider this a bug and
would ask you to open a bugzilla issue for it.

> Once I gave this some thought, it seemed to me that FailureRecorder was
> doing too much to be thought of as just a formatter.

You are absolutely right.

> At this point my solution was to add two new lifecycle methods to the
> JUnitResultFormatter interface: startAllTestSuites() and
> endAllTestSuites().  The JUnitTestRunner then invokes these methods
> and allows the recorder to write it's results.

Adding new methods to existing interfaces is a backwards compatibility
nightmare.  There are third party implementations of this interface.
This would mean we'd have to introduce a derived interface with the new
methods, retrofit FailureRecorder to implement it and complicate the
runner with instanceof checks even more.

> This could be cleaned up by adding a new "recorder" concept rather
> than heavily overloading the existing "formatter" tag.

I like this approach better.  FailureRecorder could implement both
interfaces (so existing build files using the formatter approach on it
wouldn't be broken).

Stefan

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