On Thu, Oct 2, 2025 at 9:21 AM Sandra Parsick <[email protected]> wrote:
> My 2ct to the JUnit 3 discussion: > > The last release of JUnit 3 was 2007. 18 years ago! I think that is > enough time for a migration :o). I know manual migration sucks. But > fortunately, nowadays we have tools like OpenRewrite [2] that can > automate the happy part and help automate the custom part [3]. Of > course, it depends on your customization how big the manual part will > stay. But hey, that is the known consequence of customizing. > To be honest, if you have no problem staying on JUnit 3 then you should > be okay to stay on an older Surefire plugin version that supports JUnit 3. You say that like it’s a bad thing. JUnit 3 is a mature, battle tested, and bug free product that fully serves its purpose. It works in essentially all versions of Java in use today (I think minimum is Java 1.1?)) and is thoroughly documented, supported, and understood. There haven’t been releases since 2007 because it hasn’t needed a release since 2007. If you want reliable, bug free software, you need to know when to stop. Chasing the new shiny is not sufficient reason to release. If there’s nothing that needs to be done, (and for JUnit 3 there isn’t), then nothing is precisely what you should do. I’ve talked more extensively about this here: https://www.youtube.com/watch?v=XdoUNQTDE_U&t=3745s JUnit 4 and 5 do not improve on JUnit 3, or each other. They are simply two more ways to do the same thing. The improvements I see that help developers test code are in supplementary libraries like assert4j or Guava Testlib, not the core frameworks. So if a project wants to keep using JUnit 3, it should. Burning developer time upgrading is irrational. -- Elliotte Rusty Harold [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
