[
https://issues.apache.org/jira/browse/IGNITE-10927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16746773#comment-16746773
]
Oleg Ignatenko edited comment on IGNITE-10927 at 1/18/19 11:43 PM:
-------------------------------------------------------------------
(i) upon closer inspection this task turned out much larger than anticipated.
The reason for that is that many of current tests rely on catching deprecated
{{junit.framework.AssertionFaledError}} to determine success or failure
(ClusterNodeMetricsUpdateTest, IgniteClientReconnectCacheTest,
GridCacheAbstractFullApiSelfTest, IgniteCacheConfigVariationsFullApiTest etc).
As a result, straightforward attempt to delegate assertions to respective
methods of {{org.junit.Assert}} started failing tests like mentioned above
because newer assertions throw different kind of error when failed
({{java.lang.AssertionError}}).
Above means that first step prior to delegating assertions to proper class in
JUnit 4 should be (potentially risky and massive) rework of multiple existing
tests that rely on catching outdated AssertionFailedError.
Note that although AssertionError is a superclass of AssertionFailedError, my
trial attempt to simply replace it in tests that use deprecated error class in
[PR 5840|https://github.com/apache/ignite/pull/5840] has led to multiple test
failures at teamcity meaning that this could still be troublesome.
was (Author: oignatenko):
(i) upon closer inspection this task turned out much larger than anticipated.
The reason for that is that many of current tests rely on catching deprecated
{{junit.framework.AssertionFaledError}} to determine success or failure
(ClusterNodeMetricsUpdateTest, IgniteClientReconnectCacheTest,
GridCacheAbstractFullApiSelfTest, IgniteCacheConfigVariationsFullApiTest etc).
As a result, straightforward attempt to delegate assertions to respective
methods of {{org.junit.Assert}} started failing tests like mentioned above
because newer assertions throw different kind of error when failed
({{java.lang.AssertionError}}).
Above means that first step prior to delegating assertions to proper class in
JUnit 4 should be (potentially risky and massive) rework of multiple existing
tests that rely on catching outdated AssertionFailedError.
Note that although AssertionError is a superclass of AssertionFailedError, my
trial attempt to simply replace it in tests that use deprecated error class has
led to multiple test failures at teamcity meaning that this could still be
troublesome.
> Relieve JUnit3TestLegacySupport from inheriting deprecated
> junit.framework.Assert (follow-up to IGNITE-10177)
> -------------------------------------------------------------------------------------------------------------
>
> Key: IGNITE-10927
> URL: https://issues.apache.org/jira/browse/IGNITE-10927
> Project: Ignite
> Issue Type: Sub-task
> Affects Versions: 2.7
> Reporter: Oleg Ignatenko
> Assignee: Oleg Ignatenko
> Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{JUnit3TestLegacySupport}} currently inherits deprecated
> {{junit.framework.Assert}}. This was done only in order to minimize risky
> code changes when tests were migrating from Junit 3, after
> {{GridAbstractTest}} has dropped inheriting {{junit.framework.TestCase}}.
> Now that migration is over it is less risky to cleanup project from
> deprecated assert methods and drop the harmful inheritance. In order to make
> this smoother and minimize amount of test changes, after inheritance is
> dropped, {{JUnit3TestLegacySupport}} should be extended with a set of
> "temporary patch" methods that would delegate most popular assertions used by
> subclasses to respective methods of {{org.junit.Assert}}.
> Mentioned temporary patch methods, in turn, should respective
> {{2deprecation}} notices in javadocs that would encourage developers to
> (safely and gradually) change them to direct invocations and static imports
> of respective Assert methods instead of using those inherited from
> superclass. These patch methods should be declared {{protected final}} or
> {{protected static}}, in order to minimize their applicability and prevent
> them spreading more than intended. (as a side note, experimenting has shown
> that use of {{@Deprecated}} annotation is not feasible as it deprives
> developers an option to use static imports)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
