You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by GitBox <gi...@apache.org> on 2022/01/22 21:51:19 UTC

[GitHub] [maven-surefire] CMoH edited a comment on pull request #388: [SUREFIRE-1266] Skip junit dependency check if module has no tests to run

CMoH edited a comment on pull request #388:
URL: https://github.com/apache/maven-surefire/pull/388#issuecomment-1019363784


   @Tibor17 Here is my experience bumping into this problem:
   
   1. We want to add test groups to allow running only the integration tests against a particular external service (depending on availability). After creating categories and making it work, the full multi-module build fails against some projects, including those that don't have any tests.
   2. I look at the plugin sources, and find that the check you mentioned above only looks if the test folder exists, so I dutifully remove empty `src/test` folders across my working directory. It appears the IDE has created them and well, they just stayed there.
   3. The problem persists for some of our modules, where we have hamcrest matchers in the `src/test` directory for model classes in that jar, but no tests - since there are just beans inthere anyway. We are accustomed to import the test jar in higher-level modules, thus keeping the matchers in-line with the models. This also applied to the newly introduced high-level jar that containing group definitions for the entire reactor.
   
   I imagine we can work around this limitation by extracting these out of the test artifact into a new module, having a `-test` suffix maybe, thus moving the classes from `src/test` into `src/main`, with all the management consequences (having module pairs, educating the team etc)
   
   To me, a more elegant solution was to delay the test in surefire until it can verify that the particular jar has any tests to run, which is what this contribution was about. I am confused how come others have not run into similar problems when trying to access this tagging feature of junit, because this becomes interesting later in the project, when things get complex.
   
   On the other hand, I have to reprise the branch where I was working on this idea and revisit it.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@maven.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org