Thank you Zixuan, Enrico for your insights.
It is necessary to note that assertj is only the API of assertion It is
equivalent to assertions in JUnit and TestNG, not a testing framework.
Therefore, it is only equivalent to the role of JUnit or TestNG assertion API.
And assertj assertions are also compatible with JUnit.
And in my limited read, before each release of branch, there will be a branch
freeze. Migrating only on the main branch will not affect the management of
frozen branches. As for feature migration from the main branch to the frozen
branch, it is only to change the statement of the assertion parts, not the
whole test framework.
- Roc Marshal.
At 2022-03-17 21:50:59, "Zixuan Liu" <node...@gmail.com> wrote:
>Thanks Roc,
>
>Your idea sounds great, the AssertJ is powerful, but I don't recommend
>going this path.
>
>1. There are already two test frameworks TestNG and Junit in Pulsar now, we
>should only use a test framework - TestNG, there is still some work left to
>clean up JUnit: https://github.com/apache/pulsar/pull/14065
>2. Migration is complex, we have multiple release versions, which makes
>cherry-pick difficult.
>
>Zixuan
>
>
>Enrico Olivelli <eolive...@gmail.com> 于2022年3月17日周四 20:58写道：
>
>> Roc,
>> Thanks for sharing your proposal.
>>
>> Changing the test framework will introduce lots of changes and it will
>> make it harder to share patches between branches.
>> In Pulsar we are currently maintaining 5 release lines (2.7, 2.8, 2.9,
>> 2.10 and master-2.11).
>>
>> Maybe using AssertJ for new tests can be a good compromise, like when
>> we started to use Awaitility across all modules.
>>
>> But I am not sure we want to convert the assertions on every existing test
>> case:
>> - it is a huge work
>> - we can change the meaning of some tests (even with good automated tools)
>> - (as said above) it will be hard to share patches between branches
>>
>> In my humble opinion the benefits of the migration are very little
>> compared to the risks and the waste of time
>>
>> Enrico
>>
>> Il giorno gio 17 mar 2022 alle ore 03:12 Roc Marshal <flin...@126.com>
>> ha scritto:
>> >
>> > Thank you for your research about automated toolings, Lari.
>> >
>> >
>> > As you said, if we decide to migrate, the way how we migrate it is
>> important.
>> > There is a compromise way worth discussing. AssertJ is used for
>> assertion in new tests, while module based migration can be used in the
>> migration process of old test cases, which can greatly reduce the
>> probability of conflict.
>> >
>> >
>> >
>> >
>> > - Roc Marshal.
>> >
>> > At 2022-03-17 03:46:28, "Lari Hotari" <lhot...@apache.org> wrote:
>> > >I support the switch to AssertJ.
>> > >
>> > >Some automated tooling might be useful for doing the bulk of the
>> migration.
>> > >
>> > >AssertJ provides some scripts for the migration:
>> > >
>> https://joel-costigliola.github.io/assertj/assertj-core-converting-testng-assertions-to-assertj.html
>> > >
>> > >There's also more sophisticated tools such as OpenRewrite for
>> automated refactorings. There are "recipes" for using OpenRewrite to
>> migrate from Junit asserts to AssertJ.
>> > >
>> https://docs.openrewrite.org/reference/recipes/java/testing/assertj/junittoassertj
>> > >Junit asserts are slightly different than TestNG asserts (parameter
>> order is different) so it would require modifying the OpenRewrite recipes
>> to use them for TestNG -> AssertJ refactoring.
>> > >
>> > >Before we make the switch it would be useful to experiment with the
>> tooling to see how quickly we could migrate the code base to use AssertJ.
>> > >
>> > >Migrating all at-once would result in a lot merge conflicts in all
>> in-progress pull requests and it would make cherry-picking changes to
>> maintenance branches more painful.
>> > >Do we want to go down that path?
>> > >An alternative would be to introduce AssertJ as a new library and use
>> it only for new tests.
>> > >Perhaps we could start with that?
>> > >
>> > >-Lari
>> > >
>> > >On 2022/03/16 14:03:03 Roc Marshal wrote:
>> > >> Dear devs,
>> > >>
>> > >> I'd like to start a discussion to migrate the TestNg assertion to
>> AssertJ assertion.
>> > >>
>> > >> Some main motivations are:
>> > >> - AssertJ is a pure streaming API with more elegant coding and higher
>> readability.
>> > >> - Making full use of Java 8 Lambdas for writing easier to read tests
>> and a better performing way of composing failure messages.
>> > >> - Better exception verification
>> > >> - Powerful assertion function from AssertJ.
>> > >> - Compatible with popular testing frameworks, including TestNG.
>> > >>
>> > >>
>> > >> There are some links with concise documentation:
>> > >> What is AssertJ
>> https://assertj.github.io/doc/#overview-what-is-assertj
>> > >>
>> > >> Custom assertions extension
>> https://assertj.github.io/doc/#assertj-core-custom-assertions
>> > >> Core assertion guide
>> https://assertj.github.io/doc/#assertj-core-assertions-guide
>> > >>
>> > >> Let me know what you think and I'm happy to answer all questions. Any
>> suggestions are appreciated.
>> > >>
>> > >>
>> > >> Best,
>> > >>
>> > >> Roc Marshal.
>>
