ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Павлухин Иван <vololo...@gmail.com>
Subject Re: Migration to JUnit 5
Date Sun, 24 Feb 2019 07:15:13 GMT
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

Mime
View raw message