ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Ignatenko (JIRA)" <j...@apache.org>
Subject [jira] [Created] (IGNITE-10173) Gradually move unit tests from Junit 3 to newer version
Date Wed, 07 Nov 2018 16:39:00 GMT
Oleg Ignatenko created IGNITE-10173:

             Summary: 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

(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

Step by step plan of changes is below (to be further made to sub-tasks under this "umbrella"
 # 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
 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

View raw message