> > > There is too much information and some of them are inconsistent. For > > example: > > https://issues.apache.org/jira/projects/CODEC/issues/CODEC-286 is open > > but > > https://github.com/apache/commons-codec/pull/40 is closed > > > > Maybe there should be a better integration between GH and Jira. Use GH > > Actions to change the Jira issue status on some events.
> I'm not sure I understand what this means in practice, but there > is already too much noise caused by automatic messages (whose > information contents is lower than the time it takes to figure that > out!). For example: when a pull request is merged, the final commit can include in the comment section some kind of keyword like "CLOSE-JIRA-CODEC-286" and a GitHub Action automatically closes the JIRA issue associated. Commons VFS needs help migrating to Junit 5. It still has tests on Junit 3. Let's do one step at a time. If everything goes well on CODEC, I can look into VFS. =) IntelliJ has a useful feature for helping automate migration of JUnit > tests. Works wherever you have tests that don't use rules or parameterized > tests (those need to be manually migrated still). Thanks for the tip. I'll look into it. One more practical question: since the tests are not anymore based on the methods name and are indicated by annotations now, I've seen tests without this "test" in the beginning. Looks like common practice (including it's the way it's presented in the JUnit 5 docs). Since I'll dig into all the tests, I can make this change as well. I like this style, because it looks more "clean" to me. What do you think, should I change the methods names as well? Regards, Itamar On Wed, Feb 16, 2022 at 3:15 PM Gary Gregory <garydgreg...@gmail.com> wrote: > Commons VFS needs help migrating to Junit 5. It still has tests on Junit 3. > > Gary > > On Wed, Feb 16, 2022, 13:11 Matt Sicker <boa...@gmail.com> wrote: > > > IntelliJ has a useful feature for helping automate migration of JUnit > > tests. Works wherever you have tests that don't use rules or > > parameterized tests (those need to be manually migrated still). > > > > On Wed, Feb 16, 2022 at 9:17 AM Alex Herbert <alex.d.herb...@gmail.com> > > wrote: > > > > > > On Wed, 16 Feb 2022 at 14:30, Gilles Sadowski <gillese...@gmail.com> > > wrote: > > > > > I've finally found that CODEC-285 is an issue that maybe I can help > > > > > (Upgrade to JUnit v5.6.0). But there are already 4 PRs there. I'm > > not sure > > > > > from where I should start: create a branch from the master or from > > some > > > > > branch in those PRs? Starting from the master it's possible to have > > > > > conflicts when merging all PRs. My plan is really to convert *all* > > tests in > > > > > CODEC to Junit 5. Can I do it in a single massive PR or should I > > create a > > > > > PR for each package? > > > > > > > > A good start for another post (changing the "Subject:" line). > > > > > > This has been done before in a single massive PR, e.g. for CSV [1]. > > > > > > It requires a change to use the JUnit5 pom, then a find and replace of > > > Test and Assert -> Assertions. The later requires swapping the order > > > of all messages to Assert. > > > > > > Things to watch out for are: > > > > > > - Any assertions that compare double values with a delta of zero. The > > > delta can be removed unless comparing +0.0 and -0.0. > > > - Any string formatted messages can be replaced with lambdas > > > - The try-catch pattern can be replaced with Assertions.assertThrows > > > > > > You can go ahead and start a PR on this and see how it goes. It does > > > not have to fix everything but it would be welcomed in any form as the > > > newer Junit framework indicates a continued commitment to keep the > > > project active. > > > > > > Alex > > > > > > [1] https://issues.apache.org/jira/browse/CSV-252 > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > >
