Develop Reference

Acceptance test within maven structure?

My question is about the directory location for a docker based acceptance test.
My project is a Spring Boot based command line application which extracts data from a table and builds a spreadsheet. It has unit tests and a JUnit based acceptance test. The JUnit runner for the acceptance test is a standard JUnit runner, not a Spring based runner.
Finally, I have an acceptance test structure which tests the Docker components against a dedicated DB2 instance created specifically for each test. At this point, there's a docker-compose file that:
Launches a DB2 container instance exclusively and solely for this test.
Launches a Flyway migration container to load test data.
Launches a container that does the above mentioned Spring Boot command line application.
After the close of the docker-compose, a comparison is done against the generated spreadsheet and an expected file. If they're byte for byte equivalent, the test is considered passed.
Given the acceptance test above is heavily docker laden and a few steps removed from the Java side, is it still appropriate to put this test under /src/test/acceptance?

There are many approaches to this. In general maven has two plugins: surefire and failsafe. They are very similar in terms of configurations, however surefire is mainly aimed for running unit tests, and failsafe is for integration tests.
So, first off you probably want to configure acceptance tests with a failsafe plugin. You will:
Run them during a different building phase (at least way after the unit tests run)
If your build was broken and some unit tests do not succeed you won't even want to run the acceptance/failsafe tests - it might save some build time.
You will get different reports for integration and unit tests (technically these plugins create different report folders surefire-reports and failsafe-reports)
Now to physically separate the tests you can:
Merely rely on the naming convention. These plugins look for tests named differently, say: SampleTest.class will be run with surefire while SampleTestIT.class will be run with the filesafe plugin. Of course its all customizable at the level of plugibs configurations in the pom file.
Usually unit tests are required to be put to the same package as a real class conceptually. For example: if you have a class Foo in com.myorg.Foo.java, so you place it in src/main/java/com/myorg/Foo.java and the corresponding unit test for it will be in src/main/java/com/myorg/FooTest.java. For integration tests is not usually the case so you can simply create a folder it or something and use run them with different plugins automatically, again because you'll name the tests differently.
Another approach is to separate the folders within the same module, it was already described above. So technically you maintain src/test/java and src/test/resources and next to it you will have something like src/it/java and src/it/resources. Probably you'll still want to use both surefire and failsafe plugin as I've described above. You'll still run both types of the tests in the same maven lifecycle.
The most "radical" approach is to separate the acceptance tests to different maven module. This will give you the ability to run the module with acceptance tests separately in a different build step. This might be handy in CI tool for example. Of course you can achieve a similar effect with properties or with maven profiles.

As you can refer in https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
It is optimal to have separate directories for test. I would suggest put all tests under test and have separate folder, test/acceptance/docker-test or something, but overall it is up to you.
Separate folder does help to run and de-couple different tests.

Springboot & maven - Changing datasource configuration with maven command

In my project (springboot, maven), I have tests annotated with #TestPropertySource({"classpath:flyway.properties", "/queries/test.properties"}) to override some properties related to my datasource.
I run the test with mvn clean test command.
Now I would like to add a new stage to my Jenkins pipeline to perform my tests on two different data sources.
Is there a way to overwrite the values in my file (test.properties) when I run the maven command? Or could I use two different files with spring profiles or something like :
#TestPropertySource({"classpath:flyway.properties", "/queries/test-${env/profile}.properties"})
Any insight would be gratefully appreciated. Cheers!

You could have different profiles and activate the right one on demand by running:
mvn -DargLine="-Dspring.profiles.active=myProfile" clean test

Using Spring profile and Maven Profile

I am now to Spring profile and I have a question, if I am doing a environment specific build using maven like mvn -Ptest then do I need to provide SPRING_PROFILES_ACTIVE parameter on execution.
If I understand Spring Profile correctly, giving SPRING_PROFILES_ACTIVE will direct my spring boot application to pick up the necessary application properties/#profile beans then why do I need to do mvn -Ptest.
One point I came accross is that mvn -Ptest allows us to package our properties file accordingly but in that case, isnt using Spring Profile a better solution.
It will be great if someone can point any scenario wherein we have to use mvn -Ptest even if we are using spring profile in Java application.

I think you are confusing maven profiles with spring profiles.
Maven profiles allow you to execute builds with different build configurations. It is only used during the maven build process.
Spring profiles can allow you to load different property files and is available at runtime to do whatever you want.
Now, you may have a maven profile that executes your spring application with a spring profile set but the difference is build vs execution time.

What does the "Maven Surefire plugin" means when it test your build?

I am working on understanding Maven and I'm learning about building your Java app with it.
So when I do a :
maven package
It does build my jar as expected but I see in the output console that Maven does build tests (it always say that the test a run and there are no failure).
I researched on the web about that and learned that Maven use a plugin called Maven Surefire. But I can't understand what does that plugin do to my code, what does the tests "means" ? What does the tests do with my code and how it works behind the console ?

The Maven surefire plugin runs the tests you have written. These are usually in the src/test/java folder. If you have none, the plugin does nothing.

Is this only one question? :D
So. Different things are going on.
You create an application with Java. To test the single components / packages / classes that you create most people use JUnit or TestNg. You usually have dedicated test classes that verify your production code behaves as intended without you clicking through all the things on every change.
When you now use maven to run your build the pom.xml file defines a packaging - in your case "jar" since you create a jar file. The packaging defines what set of default plugins run in the defined maven phases. You probably recognize package here. Maven executes all phases up to package and the registered / configured plugins.
To execute those tests maven provides the surefire plugin which supports running JUnit or TestNg tests. If you follow the directory conventions your tests reside in src/test/java and the surefire includes naming convention maven will execute those tests in every build (as this is the best practice). If you also want to write integration tests then there is the failsafe plugin. That plugin is not enabled by default and runs in different maven phases.
So the tests just run your production code - in fact they just do what you implement in the tests. They don't alter it in any way.
The maven introduction documentation has step by step explanations: Maven in 5 Minutes and the Getting Started Guide.
Starting from scratch this is probably a lot. So don't rush this. The build setup and test setup are very important things to have.

How can I disable Maven install and deploy phases using profiles?

My Maven project contains 3 different profiles, dev, stage, and prod, that contain different configuration settings. I would like to make it so that the install and deploy phases cannot be executed (or execute but do nothing) if the active profile is not prod, to keep dev and stage builds out of the repo. Is there a way to do this?
I'm guessing it involves adding the <plugin> to the dev and stage profiles and manually binding it to a "none" phase or something like that.

If that's what you really want to do, then just run the "package" phase on dev and staging, and in your maven settings file the provided user should not have write privileges to the repository.
What I would recommend doing, though, is to keep your configuration files outside of the build artifact, so that you only have one build that gets promoted between environments. As part of a script for deploying a build, you can automatically copy the correct settings, getting a similar effect.

Regardless of whether how you want to do this is the best idea, what you could do is use the Maven Enforcer Plugin to validate that the profile property is set to the value of your 'prod' profile. The plugin binds by default to the validate phase, so you would need to bind it to the package phase, or only the 'prod' profile will be usable.
The specific recipe I would use for this:
There's a built-in rule called requireProperty you can use to make assertions on properties and their values. You could set a property from your prod profile and then (outside any profile) configure the enforcer plugin to check to see that said property is set to the value you expect. This is hokie, however.
I strongly suggest that you externalize environment-specific configuration values into property placeholders and use profiles only to set those values rather than switching out environment-specific config files or affecting the contents of the artifact that you're generating.