Re: Fop's build process
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 med1...@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
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.hanc...@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 med1...@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
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 med1...@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.hanc...@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 med1...@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
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
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 med1...@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
