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 <clark.arc...@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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
