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 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.