xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mehdi houshmand <med1...@gmail.com>
Subject Re: Fop's build process
Date Fri, 23 Sep 2011 08:35:46 GMT
Hi Glenn,

Ok, I can leave them in, by making the changes described above
creating ant targets would be much simpler.

Mehdi

On 23 September 2011 09:16, Glenn Adams <glenn@skynav.com> 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.
>>
>> I welcome any thoughts on this, I have not have appreciated all the
>> use cases. I also intend on leaving the test-suites that are already
>> there, so that should people want to invoke these tests, they can.
>>
>> Mehdi
>>
>> On 14 September 2011 10:36, Peter Hancock <peter.hancock@gmail.com> wrote:
>> > Thanks Mehdi for considering this, thats a +1 from me.
>> >
>> > This will require some work.  A quick search on the subject of 3 to 4
>> > migration yielded quite a few guides that pointed out some pitfalls.
>> > A general recommendation, for instance, is not to mix JUnit 3 and 4
>> > conventions, e.g. est classes should not extend TestCase as this will
>> > instruct the framework to adopt JUnit 3 behavior.
>> >
>> > Unfortunately I could not find a defacto migration guide on the JUnit
>> > site, and I have no good reason to link to any other guide without
>> > evaluating  in detail.  If another member of our community has made
>> > the transition on another project and can offer advice, or perhaps can
>> > I point us to useful resources, this would be most welcomed!
>> >
>> > Thanks,
>> >
>> > Peter
>> >
>> > On Wed, Sep 14, 2011 at 10:16 AM, mehdi houshmand <med1985@gmail.com>
>> > wrote:
>> >> Hi Guys,
>> >>
>> >> I want to propose an upgrade of our test system to JUnit 4, the
>> >> benefits of upgrading can be found on plenty of blogs [1], but I just
>> >> wanted to get a feel of what everyone thought? For those that aren't
>> >> familiar with JUnit 4, it is backward compatible, so that may
>> >> alleviate some migration worries.
>> >>
>> >> [1]
>> >> http://weblogs.java.net/blog/fabianocruz/archive/2006/06/junit_4_you.html
>> >>
>> >> Mehdi
>> >>
>> >
>
>

Mime
View raw message