Thanks for Roc, sounds good. Roc Marshal <flin...@126.com> 于2022年3月18日周五 10:04写道：
> > > > 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. > >> >
