This is a good new if JUnit support both old JUnit3 style and new one.
In this case, I agree we can keep only one module and simply move to JUnit 4.6+
dependency. The only minor issue is that will force enduser to also upgrade to
JUnit 4.6+. But if it is fully backward compatible I don't see it as a drawback.
________________________________
De : Geneho Kim <[email protected]>
À : JWebUnit Development mail list <[email protected]>
Envoyé le : Vendredi, 14 Août 2009, 21h06mn 05s
Objet : Re: [JWebUnit-development] Re : Request to contribute for Port to JUnit4
Julian,
On a second thought, I don't think a separate junit3-plugin and junit4-plugins
are necessary. According to JUNIT web site, JUnit 4.6 supports both old and
version 4 tests.
It states (http://www.junit.org/taxonomy/term/11):
JUnit 4.6 is now released! There are a few bug fixes included, and
improvements to the core architecture that allow test reordering and
parallelization for basic JUnit 3 and basic JUnit 4 tests and suites.
This means that to support JUnit 4, we need the following:
(1) Add a new package net.sourceforge.jwebunit.junit4.
(2) Create new classes that are for JUnit4 in the above package, such as
WebTester and WebTestCase.
Please let me know what you think.
- Gene
On Aug 14, 2009, at 1:59 PM, Julien HENRY wrote:
Hi Clint,
>
>I will be very please to include your work of migrating to JUnit 4.
>
>Some comments:
>
>1) as far as I know we can't support 2 JUnit versions in the same Maven module
>as it is in the same groupId:artifactId. So I think it would be better to
>split in 2 separate modules. For example jwebunit-junit3-plugin and
>jwebunit-junit4-plugin.
>2) All tests are written for JUnit3. So one big part of the job would be to
>migrate all tests to JUnit4. In a first place we could keep both JUnit 3 and
>JUnit 4 tests then deprecated progressively both JUnit 3 tests and
>jwebunit-junit3-plugin.
>3) What is the purpose of the WebTestClientFactory? In case we have 2 seprate
>modules, users will only include one so they can safely inherit from
>WebTestCase (will be either JUnit3 or JUnit4 version depending on Maven
>dependency). If you prefer to have a clean separation then we can have two
>separates packages:
>net.sourceforge.jwebunit.junit.WebTestCase (old JUnit 3 is not renamed to keep
>backward compatibility)
>net.sourceforge.jwebunit.junit4.WebTestCase
>
>To sum up, according to me, here are the task that need to be done:
>1) Migrate WebTester to JUnit4
>2) Improve WebTestCase generator to handle annotation when creating JUnit4
>version of WebTestCase
>3) Migrate JUnit tests
>4) Improve project build => create 2 modules and deal with running both JUnit3
>and JUnit4 version of the tests for both HtmlUnit and Selenium plugins.
>
>If that seems too complicated for you (I can understand that) => simply focus
>on JUnit4 migration without keeping JUnit3. Even if some people complain, I
>think we can abandon JUnit3 support.
>
>Regards,
>
>Julien
>
>
>
>
________________________________
De : Geneho Kim <[email protected]>
>À : [email protected]
>Envoyé le : Vendredi, 14 Août 2009, 18h44mn 26s
>Objet : [JWebUnit-development] Request to contribute for Port to JUnit4
>
>Hi.
>My name is Clint Kim, and I'd like to contribute to JWebUnit. Mainly,
>I'd like to work on JUnit4 port.
>
>I've used HttpUnit, HtmlUnit, JUnit, over the past years. I found that
>JWebUnit to be very useful. However, my new project only works with
>JUnit 4 (company policy). Hence, I'd need port that works with JUnit 4.
>
>Here is my initial approach:
>
>* Add a new interface: net.sourceforge.jwebunit.junit.WebTestHelper
>(or WebTestSupport).
>* Add a new class:
>net.sourceforge.jwebunit.junit.WebTesterClientJUnit4 that implements
>the above interface. (This should be a package-private class)
>* Add a new class: net.sourceforge.jwebunit.api.WebTestClientFactory.
>This factory could have the following methods:
>
> public static WebTestHelper createJUnit3Instance()
> public static WebTestHelper createJunit4Instance()
>
>* Deprecate class: net.sourceforge.jwebunit.junit.WebTester
>* Make net.sourceforge.jwebunit.junit.WebTester implement WebTestHelper.
>
>If this seems to be a lot of changes, we could go with a single new
>class that uses JUnit 4 assertions (org.junit.Assert.*).
>
>Thanks,
>Clint
>
>------------------------------------------------------------------------------
>Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>trial. Simplify your report design, integration and deployment - and focus on
>what you do best, core application coding. Discover what's new with
>Crystal Reports now. http://p.sf.net/sfu/bobj-july
>_______________________________________________
>JWebUnit-development mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/jwebunit-development
>
>------------------------------------------------------------------------------
>Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>trial. Simplify your report design, integration and deployment - and focus on
>what you do best, core application coding. Discover what's new with
>Crystal Reports now.
>http://p.sf.net/sfu/bobj-july_______________________________________________
>JWebUnit-development mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/jwebunit-development
>
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
JWebUnit-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jwebunit-development
