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.
