CODEWITHSUNDEEP
unit-testingmaven-2maven
Grofit
Grofit

Reputation: 18435

Separating tests from src with Maven Project?

I've just started working on a Java project (as I usually use .net), and one of the first things that strikes me as odd is that in the Maven project there is a /src and a /test directory where obviously the source code and the tests should go.

In .net I preferred to have the tests in a separate assembly/project, so for example I would have:

That way I dont have to bloat my deployed code with any tests and it makes it easier to test my code in true isolation and in a lot of cases I didn't bother writing tests per project, I would just have solution wide unit/integration/acceptance tests i.e MySolution.UnitTests, MySolution.IntegrationTests.

However in Java it just seems to be bundled together, and I would rather separate it out, however I hear that Maven is a cruel mistress when you want to do things differently to the default structures.

So to reign this post back in, my main questions are:

Upvotes: 3

Views: 957

Answers (2)

Sean Patrick Floyd
Sean Patrick Floyd

Reputation: 298818

In a default maven setup, the tests are only executed, but not deployed.

Per convention, everything inside src/main lands in the target archive, while everything else doesn't.

Per default, a maven JAR project creates a jar with just the classes that are compiled from src/main/java. You can use different plugin goals to create:

But all of these require extra steps.

Upvotes: 2

Thilo
Thilo

Reputation: 262464

I dont have to bloat my deployed code with any tests

The deployable artifacts (jar file, war files) will not contain the test classes or data.

Is there a way to separate out the tests from the project

You could split it into two projects, with a "Test" project containing only the tests, and depending on the "real" project.

However, especially with Maven, you probably want to follow the same project layout conventions that everyone else (or at least the majority) has. This will make your life easier (less configuration).

Again, the tests will not make it into the product to be deployed, so the current layout should not be a problem.

I would just have solution wide unit/integration/acceptance tests i.e MySolution.UnitTests, MySolution.IntegrationTests.

For integration tests, that actually makes sense. In this case, define a "Test" project that depends on all the other projects that make up the solution (I'd still keep the unit tests with the project they test).

Upvotes: 6

Related Questions