0

I want to have a source folder in eclipse which is treated like test source but is ignored during the test phase. It will contain unit tests and other code which will only ever be executed manually.

  • it must appear and compile as a source folder in eclipse
  • it must compile with dependencies that have test scope
  • it will contain unit tests
  • these unit tests must not be executed during any phase of the maven lifecycle
  • the code must not be packaged as part of the build
  • I also have a source folder for unit tests which will be executed during the test phase

Is this possible and if so then how?

Edd
  • 8,402
  • 14
  • 47
  • 73
  • It's an additional test folder. I've used the build helper as I think I need it in order to have a second source folder for tests – Edd May 28 '14 at 10:43
  • Deleted my last comment after a rethink. You may find your life easier if you continue to use the normal test directories but exclude those manual tests in a different way. E.g. see [Is there a way to tell surefire to skip tests in a certain package?](http://stackoverflow.com/questions/4389744/is-there-a-way-to-tell-surefire-to-skip-tests-in-a-certain-package) as an altenative. Or consider whether the failsafe plugin is a better option (i.e. treat them as integration tests). – Duncan Jones May 28 '14 at 10:44
  • Skipping tests based on package is similar to what I'm trying to achieve but I really want to be able to skip based on source folder – Edd May 28 '14 at 10:52
  • I think this won't work unless I can compile the source folders to different destination directories – Edd May 28 '14 at 11:00
  • Adding the folder to the eclipse build path seems to work quite nicely but it's frustrating that this would add a manual step to configuring a project – Edd May 28 '14 at 11:33

3 Answers3

3

Maven is designed to force you to use a standard project setup. While some deviation is possible, sometimes it's better to look at a standard way to solve a problem.

A couple of solutions:

  1. Split the project into several modules. You could move all such tests into a new module. In Eclipse, you just import all modules. In the Maven POM, the default profile doesn't include the new module. Eclipse can remember which profiles you want to have active for a project, so you can get different behavior with static configuration.

  2. Use JUnit.Assume. In a nutshell, Assume aborts a test without making it fail. It works a bit like @Ignore. So mix the tests but add this line to all the tests that you want to run only manually:

    Assume.that(Boolean.getBoolean("runManualTests"));

    You can now run those tests by adding -DrunManualTests=true to the VM arguments. Eclipse allows you to export launch configurations so you can create a couple and put them into your project to easily run the tests.

  3. Solve the underlying problem which prevents you from running all the tests all the time. They are too slow? Use a CI server. They are brittle? Well, make them more stable. For this, I need to know more about your specific reasons.

Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820
  • I agree: these are good approaches. I would also extract the manual tests into a separate module, but that might not always be possible. A CI is also a good place for these tests. – carlspring May 28 '14 at 15:27
  • If everything else fails, then you can package the other tests into a JAR and add them as a dependency with classifier `tests`. That will make the code visible to the new module. – Aaron Digulla May 28 '14 at 15:30
  • I think using modules is a really good solution. It doesn't really work for me for reasons I'd rather not admit (I'm going with adding the folder to the build path manually in eclipse) but I feel that this is the best solution – Edd May 28 '14 at 16:40
1

The Maven Surefire Plugin is the plugin that runs the tests during your build. As per the inclusions and exclusions documentation ...

By default, the Surefire Plugin will automatically include all test classes with the following wildcard patterns:

- "**/Test*.java" - includes all of its subdirectories and all java filenames that start with "Test".
- "**/*Test.java" - includes all of its subdirectories and all java filenames that end with "Test".
- "**/*TestCase.java" - includes all of its subdirectories and all java filenames that end with "TestCase".

So, you could easily write test classes that do not follow the above mentioned patterns and still put them into the src/test/java directory. In any IDE that means they have access to the (test) build path as others, as well as they could be easily executed from that IDE. But they are not executed by Maven.

Seelenvirtuose
  • 20,273
  • 6
  • 37
  • 66
  • I can see that this would work but introducing a naming convention isn't ideal as it can be hard to communicate. I think it would lead to problems in the long run – Edd May 28 '14 at 15:22
  • @Edd Maven is all about naming conventions, and Surefire is no exception. Using a naming pattern is completely in line with the Maven philosophy. (Naming patterns may cause problems, e.g. if some other plugin happens happen to use the same naming patterns as you do. I don't know of any that looks in the `src/tst` folder, so for this particular question is should be okay.) – toolforger May 09 '21 at 11:14
0

I think you're looking at it from the wrong angle. If I were you, I would create a <profile/> and define in the maven-surefire-plugin's settings (of the profile) that *My*Test should be executed when this profile is activated. Actually, I would create two separate profiles -- one that would be <activeByDefault/> (that would exclude the My*Test and only be activated, if a <property/> is not specified from the command-line); and another profile with an <activation/> based on a property -- this profile you will manually trigger by passing in -Dmy.test.property, for example. This way you will avoid all the black magic with the build-helper-maven-plugin.

carlspring
  • 31,231
  • 29
  • 115
  • 197
  • I don't think the folder would appear as a source folder in eclipse using this method – Edd May 28 '14 at 15:18
  • What I'm suggesting is this: put your "manual" tests under `src/test/java`, but make sure they match some sort of unique pattern like, say, "*ManualTest.java". This way the code will still be treated like source and will be in the proper place. Also, code under `src/test/java` does not enter the final artifact, anyway. – carlspring May 28 '14 at 15:25
  • `*ManualTest.java` will still trigger Surefire's "look for tests in this file" mechanism, so one should use a different naming convention. – toolforger May 09 '21 at 11:15