ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikolay Izhikov <nizhi...@apache.org>
Subject Re: Migration to JUnit 5
Date Mon, 25 Feb 2019 13:54:48 GMT
Hello, Ivan.

May be I miss some mail - if yes, can you repeat it.
What is advantages of migration from junit 4 to 5?
Why we should do it?


пн, 25 февр. 2019 г. в 16:33, Ivan Fedotov <ivanan639@gmail.com>:

> Ivan,
> That is my thoughts according to your questions.
>
> 1. I tried to implement test suits with JUnit4 compatibility layer. The
> basic concept is to use @RunWith(JUnitPlatform.class) @SelectClasses
> ({...})[1] and on
> CI Ignite it works fine.
>
> 2. According to @Rules, there are several ways to solve it:
>     2.1 Leave JUnit4 code without changes. It will work because of Vintage
> module
>     2.2 Rewrite the @Rule as an Extension. The work of extension is similar
> to the @Rules work, but it is extracted in an Extension class.
>     For more information about extensions, please, follow the IEP [2].
> In my opinion, the easiest and the most understandable way is to leave
> GridAbstractTest in current form. It will work with JUnit5
> syntaxis and abilities.
>
> 3. I faced a couple of problems during dealing with dynamic and static
> tests in one project with JUnit5. The problem occurs with surefire version:
> static tests work fine with 2.21x and earlier and with dynamic tests, the
> situation is vice versa, it works with > 2.21x surefire version.
> We can use helpful surefire dependency to use static tests with the newest
> surefire version [3], but dynamic tests become unavailable from pure
> Maven and accordingly from CI Ignite (from IDE all is fine).
> I can suggest leaving this type of tests on JUnit4 on the current stage -
> they are in the vast minority.
>
> Let me comment on your side notes.
>
> I am not against the stable and widely-used test library usage. All I want
> to say that it is not necessary in case of the main testing Ignite
> framework (Junit) already provides the mentioned features.
>
> At the initial stage of improvements 3->4 I am planning to remove
> JUnit3TestLegacyAssert, JUnit3TestLegacySupport classes. I guess that
> during this work
> I will face with an issue that you are mentioned - turning instance methods
> to static. It is because of beforeTestsStarted and afterTestsStarted
> methods - I want to replace them by methods with BeforeAll, AfterAll
> annotations. But the point is that methods under such annotations must be
> static. Just now I am not sure about fully removing
> GridCommonAbstractTest class, but the need for static methods is a fact.
>
> [1]
>
> https://github.com/apache/ignite/blob/85ba3a88d661bb05bbb749bd1feaf60cd9099ddc/examples/src/test/java/org/apache/ignite/testsuites/IgniteExamplesSelfTestSuite.java#L59
> [2]
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5
> [3] https://github.com/junit-team/junit5/issues/1778
>
> вс, 24 февр. 2019 г. в 10:15, Павлухин Иван <vololo100@gmail.com>:
>
> > Ivan,
> >
> > Indeed junit5 has a lot of powerful features which can improve testing
> > process.
> >
> > But first we should go through a migration process. There are several
> > items which looks quite challenging.
> > 1. Test suites support. Correct me if I am missed it, but I have not
> > found a concept of test suites similar to junit3/4 ones. CI in Ignite
> > heavily depends on test suites. Is there an alternative in junit5?
> > 2. The majority of our tests extend GridAbstractTest which in fact is
> > a core class in Ignite testing. Writing a test without extending it is
> > not a good idea. Currently it employs number of junit4 concepts, e.g.
> > test rules which as I saw are not supported in junit5. So, it sounds
> > that some changes in GridAbstractTest need to be done. During
> > migration from junit 3 to 4 GridAbstractTest used kind of mimicry, it
> > can be used as a base class for junit3 and junit4 tests at the same
> > time. How can we address transitional period now?
> > 3. Also we have bunch of tests using our home-brewed parametrization.
> > You can find them by searching usages of
> > ConfigVariationsTestSuiteBuilder. This part was rather tricky during
> > migration to junit4.
> >
> > Do we have a plan for all these items?
> > ----
> >
> > Couple of side notes.
> >
> > Regarding dependencies minimization. Actually, I think it is important
> > for junit itself as a library. Many libraries try to minimize
> > dependency. In Ignite we do so as well. But in my opinion it is not
> > the case in context of libraries used during testing. If we have
> > useful, stable and widely-used test library which can improve our
> > processes why should not we use it?
> >
> > Regarding removing leftovers left after junit 3->4 migration.
> > Actually, I think that GridAbstractTest and GridCommonAbstractTest can
> > be refactored in order to simplify further development and migration
> > to new testing framework. For example, there are a lot of instance
> > methods which can be turned to static methods. Various start/stopGrid
> > methods fall into this category. They can be extracted into some
> > utility class and imported statically. Perhaps, after number of such
> > refactoring we will be able to write tests without extending
> > GridCommonAbstractTest.
> >
> > пт, 22 февр. 2019 г. в 18:33, Ivan Fedotov <ivanan639@gmail.com>:
> > >
> > > Hi Ivan!
> > >
> > >  Junit5 differs from JUnit4 not so strong as 4 from 3 version. Of
> course,
> > > we can use AssertJ and other libraries, but it is more comfortable to
> > > use functionality from the box. Moreover, the JUnit team provides
> strong
> > > support for its products and it is the core JUnit principle - minimize
> > > third-party dependency [1].
> > >
> > >  According to Parameterized tests, it has several cons in JUnit4:
> > >  1. Test classes use fields and constructors to define parameters,
> which
> > > make tests more verbose
> > >  2. It requires a separate test class for each method being tested.
> > >  In JUnit5 it has a simplified parameter syntax and supports multiple
> > > data-set source types, including CSV and annotation
> > >
> > >  Impact on daily test development does not so differ from development
> on
> > > JUnit4. We also can use annotations to mark methods as tests, but some
> > main
> > > annotations have
> > > different names - you can see it in the ticket description [2]. You
> have
> > to
> > > use those annotations and different import, but these are minor
> changes.
> > >  We can change suites from static to dynamic tests [3], but I am not
> sure
> > > that it is necessary. If you have any arguments in favor of dynamic
> > tests,
> > > I am ready to discuss them.
> > >
> > >  Now I see that changes in GridAbstractTest are not required. Only
> > > improvements in JUnit 3->4 migration, which were given in IEP. Other
> > JUnit5
> > > features we can use with additional imports. The problem can appear
> with
> > > dynamic tests because we can not launch static and dynamic under one
> > > surefire version. I made a preliminary migration on examples module,
> you
> > > can take a look on it [4], but now it is still in work.
> > >
> > > I tried to find some other JUnit5 features and added them to IEP. If I
> > miss
> > > something, please, let me now, we will also take it into account.
> > >
> > >  [1] https://github.com/junit-team/junit5/wiki/Core-Principles
> > >  [2] https://issues.apache.org/jira/browse/IGNITE-10958
> > >  [3] https://www.baeldung.com/junit5-dynamic-tests
> > >  [4] https://github.com/apache/ignite/pull/5888
> > >
> > >
> > > чт, 21 февр. 2019 г. в 18:45, Павлухин Иван <vololo100@gmail.com>:
> > >
> > > > Hi Ivan,
> > > >
> > > > Thank you for your efforts!
> > > >
> > > > I checked a section "Motivation" in IEP and I think that we should
> add
> > > > more details there. You provided mostly examples of more convenient
> > > > assertions. But there are other options to deal with it. E.g. AssertJ
> > > > library [1] (I think that we can consider it even after migration to
> > > > junit5). It would be great if we can describe some junit5 features
> > > > which can make our life simpler and there is no alternative in
> junit4.
> > > > E.g. we have the similar Parameterized concept in junit4, so it does
> > > > not look as a big win here.
> > > >
> > > > Also, an impact on everyday development should be estimated. As I
> > > > know, junit5 has a compatibility layer which allows to migrate from
> > > > junit4 seamlessly. But as I understood you would like to use new
> > > > junit5 features. And we have well-known GridAbstractTest which
> > > > historically was bound to junit3, now is bound to junit4. Should we
> > > > change it significantly for junit5? Should we change other existing
> > > > tests? Suites?
> > > >
> > > > Could you please address my concerns?
> > > >
> > > > Let's discuss pros and cons. I will be happy to help there.
> > > >
> > > > [1] http://joel-costigliola.github.io/assertj/
> > > >
> > > > чт, 21 февр. 2019 г. в 18:07, Ivan Fedotov <ivanan639@gmail.com>:
> > > > >
> > > > > Dmitriy, thank you, access is fine.
> > > > >
> > > > > I have created the corresponding IEP [1].
> > > > >
> > > > > Now I am going to continue work on this. If somebody has any
> > suggestions
> > > > or
> > > > > additions I am ready to discuss them.
> > > > >
> > > > > [1]
> > > > >
> > > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5
> > > > >
> > > > > чт, 21 февр. 2019 г. в 01:42, Dmitriy Pavlov <dpavlov@apache.org>:
> > > > >
> > > > > > Done, please check access now.
> > > > > >
> > > > > > ср, 20 февр. 2019 г. в 21:49, Ivan Fedotov <ivanan639@gmail.com
> >:
> > > > > >
> > > > > > > Dmitriy, thank you for the response.
> > > > > > >
> > > > > > > My wiki username is "ivanan", the related mailbox is
> > > > ivanan639@gmail.com
> > > > > > .
> > > > > > >
> > > > > > > ср, 20 февр. 2019 г. в 18:38, Dmitriy Pavlov <
> dpavlov@apache.org
> > >:
> > > > > > >
> > > > > > > > Hi Ivan,
> > > > > > > >
> > > > > > > > Now admin service is unavailable (gives error 503).
I'll add
> > rights
> > > > > > once
> > > > > > > it
> > > > > > > > is up and running.
> > > > > > > >
> > > > > > > > Could you share your wiki username? I can't find any
users
> who
> > > > signed
> > > > > > up
> > > > > > > in
> > > > > > > > the wiki with any similar email/username
> > > > > > > >
> > > > > > > > Sincerely,
> > > > > > > > Dmitriy Pavlov
> > > > > > > >
> > > > > > > > ср, 20 февр. 2019 г. в 18:26, Ivan Fedotov
<
> > ivanan639@gmail.com>:
> > > > > > > >
> > > > > > > > > Hi, Igniters.
> > > > > > > > >
> > > > > > > > > I am planning to formalize migration to JUnit5
and create
> IEP
> > > > which
> > > > > > > will
> > > > > > > > > include related issues.
> > > > > > > > >
> > > > > > > > > I already started to work on one of the issues
[1] and
> > created a
> > > > > > draft
> > > > > > > > for
> > > > > > > > > the corresponding IEP [2].
> > > > > > > > >
> > > > > > > > > Please, give me rights for confluence to create
IEP.
> > > > > > > > >
> > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-10973
> > > > > > > > > [2]
> > > > https://gist.github.com/1vanan/1f81319f1dc6d6ebca30c216fdd82759
> > > > > > > > >
> > > > > > > > > Sincerely,
> > > > > > > > > Ivan Fedotov.
> > > > > > > > >
> > > > > > > > > ivanan639@gmail.com
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Ivan Fedotov.
> > > > > > >
> > > > > > > ivanan639@gmail.com
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Ivan Fedotov.
> > > > >
> > > > > ivanan639@gmail.com
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Ivan Pavlukhin
> > > >
> > >
> > >
> > > --
> > > Ivan Fedotov.
> > >
> > > ivanan639@gmail.com
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
> >
>
>
> --
> Ivan Fedotov.
>
> ivanan639@gmail.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message