[
https://issues.apache.org/jira/browse/IGNITE-10173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10173:
------------------------------------
Description:
(i) Related dev list discussion: [Is it time to move forward to JUnit4
(5)?|http://apache-ignite-developers.2346864.n4.nabble.com/Is-it-time-to-move-forward-to-JUnit4-5-td29608.html]
Currently unit tests in the project are mix of two versions Junit 3 and 4. This
makes it hard to develop and maintain. Making all tests use the same version
Junit is intended to address this problem.
Another reason why migration to newer version is desirable is Junit 4 provides
developer an option to conveniently mute tests by Ignore annotation while with
Junit 3 this could only be done by adding fail and manually muting the test in
Teamcity (the latter turned out to be extremely painful when I had to do some
things per IGNITE-9884).
This task is to migrate all tests to single uniform version Junit 4 (with
further option to migrate to Junit 5, see also note below).
The difficulty of migration is that too many tests depend on Junit3-based
[GridAbstractTest|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java]
and its subclasses so that making them all change in a single move would be
very tedious and risky. A way to work around this is to create a parallel
Junit-4 based "twin" of GridAbstractTest (tentative name
{{IgniteAbstractTest}}) and using is move to Junit 4 gradually, smoothly and
safely.
Step by step plan of changes is below (made to sub-tasks under this "umbrella"
ticket):
# migrate examples tests from Junit 3 to 4
This is first task because examples are most publicly visible, relativelly
small and least risky part of unit tests in the project.
Steps: 1) create Junit-4 based twin of GridAbstractTest (and all needed
subclasses), 2) declare GridAbstractTest deprecated with reference to use newer
API instead 3) change unit tests in examples to use new API
# migrate core module tests from Junit 3 to 4
using new API introduced and tested at prior step
# migrate non-core modules tests from Junit 3 to 4
using new API introduced and tested at prior step
# cleanup Junit 3 from the project
1) remove deprecated API of GridAbstractTest and its subclasses 2) remove
dependencies from Junit 3 in Maven 3) migrate tests that were missed at prior
steps, if there are any
# change tests that fail("Ignite JIRA ticket URL") to @Ignore("Ignite JIRA
ticket URL")
Note this step would better be coordinated with Teamcity and TC bot
maintainers because it may substantially impact them
# Change new tests root to use @BeforeClass and @AfterClass instead of
isFirstTest() and isLastTest()
these homebrew methods seem to be in GridAbstractTest only because Junit 3
lacked necessary functionality; after migration to Junit 4 these would better
changed to use standard API of this framework.
# Investigate migration from Junit 4 to 5
Find out if Junit 5 is mature enough - specifically why maven still uses Junit
4 as default, are there serious reasons for that or not. If it looks okay,
create a new JIRA task to migrate.
----
Note on migrating to Junit 5. While preparing this task I considered an option
to migrate from Junit 3 to 5 instead of 4.
I dropped that primarily because migration from Junit 3 requires quite a lot of
manual changes in the code (changing imports and adding annotations), as
opposed to migration from Junit 4 to 5 for which there seem to be options to
make most changes automatically (eg IntelliJ seem to provide such an option).
Because of that it looks more convenient to split it to separate steps, so that
after all tests in the project get to Junit 4 we could do an automated
migration to newer version.
Another thing that made me prefer this way is that I wanted to avoid having
three different versions Junit in the project (3, 4, 5), even if that would be
temporarily (note that migration from Junit 3 is expected to be manual and
quite lengthy, so "temporarily" may mean quite a lot of time really).
Also note that as pointed in above list of steps we better make some
preliminary assessment on whether time has really come to migrate to Junit 5.
was:
(i) Related dev list discussion: [Is it time to move forward to JUnit4
(5)?|http://apache-ignite-developers.2346864.n4.nabble.com/Is-it-time-to-move-forward-to-JUnit4-5-td29608.html]
Currently unit tests in the project are mix of two versions Junit 3 and 4. This
makes it hard to develop and maintain.
Another reason why migration to newer version is desirable is Junit 4 provides
developer an option to conveniently mute tests by Ignore annotation while with
Junit 3 this could only be done by adding fail and manually muting the test in
Teamcity (the latter turned out to be extremely painful when I had to do some
things per IGNITE-9884).
This task is to migrate all tests to single uniform version Junit 4 (with
further option to migrate to Junit 5, see also note below).
The difficulty of migration is that too many tests depend on Junit3-based
[GridAbstractTest|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java]
and its subclasses so that making them all change in a single move would be
very tedious and risky. A way to work around this is to create a parallel
Junit-4 based "twin" of GridAbstractTest (tentative name
{{IgniteAbstractTest}}) and using is move to Junit 4 gradually, smoothly and
safely.
Step by step plan of changes is below (made to sub-tasks under this "umbrella"
ticket):
# migrate examples tests from Junit 3 to 4
This is first task because examples are most publicly visible, relativelly
small and least risky part of unit tests in the project.
Steps: 1) create Junit-4 based twin of GridAbstractTest (and all needed
subclasses), 2) declare GridAbstractTest deprecated with reference to use newer
API instead 3) change unit tests in examples to use new API
# migrate core module tests from Junit 3 to 4
using new API introduced and tested at prior step
# migrate non-core modules tests from Junit 3 to 4
using new API introduced and tested at prior step
# cleanup Junit 3 from the project
1) remove deprecated API of GridAbstractTest and its subclasses 2) remove
dependencies from Junit 3 in Maven 3) migrate tests that were missed at prior
steps, if there are any
# change tests that fail("Ignite JIRA ticket URL") to @Ignore("Ignite JIRA
ticket URL")
Note this step would better be coordinated with Teamcity and TC bot
maintainers because it may substantially impact them
# Change new tests root to use @BeforeClass and @AfterClass instead of
isFirstTest() and isLastTest()
these homebrew methods seem to be in GridAbstractTest only because Junit 3
lacked necessary functionality; after migration to Junit 4 these would better
changed to use standard API of this framework.
# Investigate migration from Junit 4 to 5
Find out if Junit 5 is mature enough - specifically why maven still uses Junit
4 as default, are there serious reasons for that or not. If it looks okay,
create a new JIRA task to migrate.
----
Note on migrating to Junit 5. While preparing this task I considered an option
to migrate from Junit 3 to 5 instead of 4.
I dropped that primarily because migration from Junit 3 requires quite a lot of
manual changes in the code (changing imports and adding annotations), as
opposed to migration from Junit 4 to 5 for which there seem to be options to
make most changes automatically (eg IntelliJ seem to provide such an option).
Because of that it looks more convenient to split it to separate steps, so that
after all tests in the project get to Junit 4 we could do an automated
migration to newer version.
Another thing that made me prefer this way is that I wanted to avoid having
three different versions Junit in the project (3, 4, 5), even if that would be
temporarily (note that migration from Junit 3 is expected to be manual and
quite lengthy, so "temporarily" may mean quite a lot of time really).
Also note that as pointed in above list of steps we better make some
preliminary assessment on whether time has really come to migrate to Junit 5.
> Gradually move unit tests from Junit 3 to newer version
> -------------------------------------------------------
>
> Key: IGNITE-10173
> URL: https://issues.apache.org/jira/browse/IGNITE-10173
> Project: Ignite
> Issue Type: Task
> Affects Versions: 2.6
> Reporter: Oleg Ignatenko
> Assignee: Oleg Ignatenko
> Priority: Major
> Labels: MakeTeamcityGreenAgain, technical_debt
>
> (i) Related dev list discussion: [Is it time to move forward to JUnit4
> (5)?|http://apache-ignite-developers.2346864.n4.nabble.com/Is-it-time-to-move-forward-to-JUnit4-5-td29608.html]
> Currently unit tests in the project are mix of two versions Junit 3 and 4.
> This makes it hard to develop and maintain. Making all tests use the same
> version Junit is intended to address this problem.
> Another reason why migration to newer version is desirable is Junit 4
> provides developer an option to conveniently mute tests by Ignore annotation
> while with Junit 3 this could only be done by adding fail and manually muting
> the test in Teamcity (the latter turned out to be extremely painful when I
> had to do some things per IGNITE-9884).
> This task is to migrate all tests to single uniform version Junit 4 (with
> further option to migrate to Junit 5, see also note below).
> The difficulty of migration is that too many tests depend on Junit3-based
> [GridAbstractTest|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java]
> and its subclasses so that making them all change in a single move would be
> very tedious and risky. A way to work around this is to create a parallel
> Junit-4 based "twin" of GridAbstractTest (tentative name
> {{IgniteAbstractTest}}) and using is move to Junit 4 gradually, smoothly and
> safely.
> Step by step plan of changes is below (made to sub-tasks under this
> "umbrella" ticket):
> # migrate examples tests from Junit 3 to 4
> This is first task because examples are most publicly visible, relativelly
> small and least risky part of unit tests in the project.
> Steps: 1) create Junit-4 based twin of GridAbstractTest (and all needed
> subclasses), 2) declare GridAbstractTest deprecated with reference to use
> newer API instead 3) change unit tests in examples to use new API
> # migrate core module tests from Junit 3 to 4
> using new API introduced and tested at prior step
> # migrate non-core modules tests from Junit 3 to 4
> using new API introduced and tested at prior step
> # cleanup Junit 3 from the project
> 1) remove deprecated API of GridAbstractTest and its subclasses 2) remove
> dependencies from Junit 3 in Maven 3) migrate tests that were missed at prior
> steps, if there are any
> # change tests that fail("Ignite JIRA ticket URL") to @Ignore("Ignite JIRA
> ticket URL")
> Note this step would better be coordinated with Teamcity and TC bot
> maintainers because it may substantially impact them
> # Change new tests root to use @BeforeClass and @AfterClass instead of
> isFirstTest() and isLastTest()
> these homebrew methods seem to be in GridAbstractTest only because Junit 3
> lacked necessary functionality; after migration to Junit 4 these would better
> changed to use standard API of this framework.
> # Investigate migration from Junit 4 to 5
> Find out if Junit 5 is mature enough - specifically why maven still uses
> Junit 4 as default, are there serious reasons for that or not. If it looks
> okay, create a new JIRA task to migrate.
> ----
> Note on migrating to Junit 5. While preparing this task I considered an
> option to migrate from Junit 3 to 5 instead of 4.
> I dropped that primarily because migration from Junit 3 requires quite a lot
> of manual changes in the code (changing imports and adding annotations), as
> opposed to migration from Junit 4 to 5 for which there seem to be options to
> make most changes automatically (eg IntelliJ seem to provide such an option).
> Because of that it looks more convenient to split it to separate steps, so
> that after all tests in the project get to Junit 4 we could do an automated
> migration to newer version.
> Another thing that made me prefer this way is that I wanted to avoid having
> three different versions Junit in the project (3, 4, 5), even if that would
> be temporarily (note that migration from Junit 3 is expected to be manual and
> quite lengthy, so "temporarily" may mean quite a lot of time really).
> Also note that as pointed in above list of steps we better make some
> preliminary assessment on whether time has really come to migrate to Junit 5.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
