1) Open a bug tracker in sourceforge (you need to register)
2) Try to write a minimal JUnit test that reproduce the bug
3) Fix the code
4) Create a patch file containing both the JUnit test and the fix (patch from
trunk)
5) Upload the patch in the bug tracker
6) Wait for someone to review it and give feedback
If you can't provide a JUnit test then simply provide the patch with the fix.
But in OSS world it means you may have to wait longer because someone will have
to review it much more deeper.
Regards,
Julien
________________________________
De : Geneho Kim <[email protected]>
À : JWebUnit Development mail list <[email protected]>
Envoyé le : Vendredi, 14 Août 2009, 21h13mn 48s
Objet : Re: [JWebUnit-development] Re : Request to contribute for Port to JUnit4
Julien,
I have one more question. I think I found a bug in the code. What do I need to
do to report and fix it? I'm new to open source development, and really
appreciate your help.
Thanks,
- Clint
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
