You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by mehdi houshmand <me...@gmail.com> on 2011/09/14 11:16:33 UTC
Fop's build process
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
Re: Fop's build process
Posted by mehdi houshmand <me...@gmail.com>.
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 <gl...@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 <me...@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 <pe...@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 <me...@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
>> >>
>> >
>
>
Re: Fop's build process
Posted by Simon Pepping <sp...@leverkruid.eu>.
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 <me...@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.
Re: Fop's build process
Posted by Glenn Adams <gl...@skynav.com>.
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 <me...@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 <pe...@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 <me...@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
> >>
> >
>
Re: Fop's build process
Posted by mehdi houshmand <me...@gmail.com>.
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 <pe...@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 <me...@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
>>
>
Re: Fop's build process
Posted by Peter Hancock <pe...@gmail.com>.
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 <me...@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
>