Hi, in the last few days I've been working on switching our large mass of JUnit 3 tests to JUnit 4.
The original plan was simple: let IntelliJ do most of the job, with its automatic migration, and then fill in the blanks. Turned out IntelliJ is very good at migrating simple JUnit tests, but not tests that inherit from other base test classes... which is a pattern very widely used in GeoTools. Long story short, IntelliJ migrated some 250 tests, but I had to modify more or less twice as that by "hand"... where hand means, mostly regex replacements with extra actual "by hand" changes. The final PR modifies 870 files: https://github.com/geotools/geotools/pull/3306 It was an epic endeavour. Some highlights follow: - Classes had a lot of needless cruft, like suite methods manually collecting the test methods, or "main" with runners. Wiped them all out. - JUnit3 had an equals between doubles without a tolerance, switching to JUnit4 all these calls required the tolerance param to be added (the old method is there, but deprecated) - The test compile in Maven complains if a class with JUnit 4 annotations has methods whose name matches ".*test.*", and breaks the compile. That was pretty useful to locate methods that the regexes missed. It also meant changing test methods that were disabled by adding a prefix to "test" (e.g.. xtestMyCase), and annotating them with both @Test and @Ignore. - There was still a risk of having less tests after the migration, so I've made a sequential build both on the current master and in the branch, and compared. Found I missed a few test classes and added them back. The final result is that the build runs a few more tests than the current master, as there were test methods disabled that were actually passing! So all of this is great eh? Hem... nope, not quite as I hoped at least. My last step was to add PMD checks to ensure no new JUnit3 tests could be added. Created a custom PMD rule for it, based on type matching (sort of a XPath match), and found I had to disable it for OnlineTest. Nice! But then I noticed it would not fail in imagemosaicjdbc, where there is a separate base class for online test (why it could not use OnlineTest, it's beyond me)... why oh why? And then it dawned on me.... PMD is actually not running on test sources! It needs a dedicated flag <https://maven.apache.org/plugins/maven-pmd-plugin/pmd-mojo.html#includeTests> to do so. So, all the test sources, they have never been gone though the PMD checks. First, I've tried to set-up the maven build so that different checks are run on main sources and tests... and failed. The attempt tried to use two different executions, linked to different phases, giving each a different PMD configuration, and found it was ignoring my config, solid.... this is due to an issue in the PMD plugin, it only honors the configuration under plugin, ignoring the eventual one in executions: https://issues.apache.org/jira/browse/MPMD-132 Long story short, the above PR does not contain any new PMD check, as they do nothing on tests anyways. Plan to move forward: - Complete the migration on GWC and GS (should be much quicker, most GeoServer tests are JUnit 4 already). - Go back, and enable PMD on tests as well. That's gonna be epic too, gt-main alone contains a few hundred failures... but oh well, at this point I've become decently good at resolving them :-D - Finally, take a stab at migrating the OnlineTest family as well. Cheers Andrea == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- *Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.*
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel