xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Pepping <spepp...@leverkruid.eu>
Subject Re: Fop's build process
Date Tue, 27 Sep 2011 08:23:01 GMT
Upgrading the test setup to JUnit4 is fine with me.

The current options to run single tests and to disable tests are
useful; a new test setup should keep those options. Otherwise any
simplification and improvement of the test system is fine with me.

Simon

On Fri, Sep 23, 2011 at 04:16:03PM +0800, Glenn Adams wrote:
> i would suggest you simply create a new target that invokes tests in the
> fashion you propose; however, i would not want to replace the current
> targets with this new target, or at least not do so without considerable
> usage having passed;
> 
> i personally like having different targets, particularly when creating new
> tests or debugging regressions in tests, since that allows me to effectively
> subset the tests from command line based on which targets i select;
> 
> On Fri, Sep 23, 2011 at 3:57 PM, mehdi houshmand <med1985@gmail.com> wrote:
> 
> > Hi Guys,
> >
> > Since there's been overwhelming support for this, I'll throw another
> > thought out there for people to consider. While looking at these
> > tests, it seems logical to me to change the way FOP invokes the JUnit
> > tests, so that rather than invoking test-suites, the build.xml,
> > invokes ALL classes that match the regex "*TestCase.java".
> >
> > The benefit of this would be that if someone forgets to add a unit
> > test to a test suite, the test is still invoked, but more importantly,
> > it would greatly simplify the build.xml. This would also mean that the
> > layout/area tree/IF test-suites will have to change to take advantage
> > of the JUnit4 parametrised test system. But that's not difficult to
> > do, and quite frankly I don't like that they depend on so many obscure
> > system parameters, I appreciate that that's the only way to
> > parametrise tests in JUnit3, but this gives us an opportunity to
> > improve it. This also has the added benefit that people can run these
> > tests in their IDE without having to inject system parameters.

Mime
View raw message