[
https://issues.apache.org/jira/browse/IGNITE-10173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10173:
------------------------------------
Fix Version/s: 2.8
> 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
> Fix For: 2.8
>
>
> (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)
