+1 for moving the tests to the code as well. However... I would be careful to check what is packaged in the `tests` artifact produced by the build. Should we package the test transient dependencies? Otherwise it will be complicated to run multiple test artifacts under one build, with different tests having different dependencies. e.g. tests with dep to a different version of the sling-testing-rules. And speaking of running multiple tests together in a different job, one big concern (if we decide to do some magic) is classpath shadowing. I've seen the following happen:
A maven project that 1. Collected multiple tests modules 2. Collected their dependencies 3. Ran failsafe on that dir, sharing the classpath Sounds ok, but it isn't. because of classpath shadowing. So because of complications like these, I'd second Valentin's slight concern and make them a different maven module and put the tests in src/main. Arguably makes it a bit easier to manage what's packaged inside and how they're ran together? WDYT? - Andrei On Fri, Nov 9, 2018 at 2:28 PM Robert Munteanu <romb...@apache.org> wrote: > On Fri, 2018-11-09 at 13:50 +0100, Georg Henzler wrote: > > +1 to move the tests closer to the code. > > > > Regarding the path src/test/it (mentioned in the wiki page): > > Shouldn't > > we rather stick with src/test/java for both ITs and regular tests > > and > > just use the standard name conventions as configured by default for > > plugins surefire/failsafe maven plugins, that is *Test.java [1] for > > unit > > tests and *IT.java [2] for integration tests? > > > Yes, you're right. > > I'll update the wiki page. And also this is what I'm doing in my POC, > see [3] > > Robert > > []3; > https://github.com/apache/sling-org-apache-sling-servlets-get/compare/feature/SLING-7936 > >
