DO NOT REPLY [Bug 46962] [PATCH] Deadlock in PropertyCache class

2011-09-27 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=46962

--- Comment #12 from Simon Pepping  2011-09-27 08:25:35 
UTC ---
(In reply to comment #9)
> Some of the tests added require Mockito, I tried to avoid using mocking as 
> much
> as possible for the obvious reason that the commiters haven't agreed to add it
> as a dependency. However, some of these classes were are a nightmare to test
> without mocking them.

I have no problem with the addition of Mickito to FOP's dependencies, since it
helps writing true unit tests.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.


Re: Fop's build process

2011-09-27 Thread Simon Pepping
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.