using maven we create a war file and we need to be deployed this war in tomcat(application server) for different environment (DEV/QA/UAT).
We need to run the JUNIT test for each of the environment before deploying.
we have written nearly 60 junit test which need to passed
Is is possible to run the junit test for war file?
if yes how to run all junit test sitting inside the war file
WAR file is deployment artifact that shouldn't include any unit tests. As #Gerold Broser correctly pointed out, Maven handles excluding of unit tests for you if you place them into "src/test/java". Don't ever try to put them into "src/main/java".
we have written nearly 60 junit test which need to passed
Is is possible to run the junit test for war file?
If they are true unit tests, they don't need to be executed against deployed war service. They are testing small chunks of functionality and are generally executed during test phase of maven lifecycle.
If tests are firing requests against deployed server, at that stage they are not unit tests anymore and should be probably placed into separate test project.
Proper place where to run your tests is always Continuous Integration server, so one way or the other make sure that execution is automated! Tests without CI server are waste of time.
BTW
There is maven-tomcat7-plugin to start tomcat and deploy it during interation-test phase of Maven lifecycle, but this maven plugin doesn't seem to be maintained anymore and doesn't work with Servlet 3.0 Java configs and Tomcat 8. So I don't recommend that path.
Related
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.
We have a suite of JBehave tests which we run on a scheduled job to health check a web service.
On every run, maven downloads dependencies and continues through the rest of its lifecycle before running the tests.
In order to speed up the test execution, is it possible to package the tests within an executable jar along with the associated dependencies and run that instead of using Maven?
Is it possible to execute a lifecycle target (e.g. integration-test) on an artefact that has been installed within the local repo?
My use case is as follows. I have a multi module project with many modules that dedicated various types of integration testing (compliance test, performance tests, etc). I need to invoke these integration multiple times with different environment configurations. These configurations are expressed as maven profiles and parameterised using properties. I want to avoid recompiling the project over and over again.
I would like to have one build CI job performing the mvn install, then separate CI jobs performing the integration tests, triggered once the build CI job has passed. The integration tests would simply invoke integration-test lifecycle phase of the installed artefact setting the profile and passing the parameters
I have tried pointing mvn at the .pom file within the local repo but this does not work. It fails because it cannot find classes within the artefact's own JAR file (as if it were not being put on the classpath) - a problem that doesn't occur if I have my integration job checkout the tree and invoke the pom.xml within the source tree.
mvn -f ~/.m2/repo/x/y/z/myproj-perftests-x.x.x-SNAPSHOT.pom integration-test -Pmyprofile -Dparam1=blah
No, it is not possible. Maven plugins (normally) only work with project sources.
If your only concern is recompiling project again and again, consider splitting your project into the core part and the integration tests part. Then when running integration tests you'll only need to recompile the integration tests part.
I have just started using Jenkins for a small project and as part of that, would like the unit tests to be run every time it builds.
I understand that you need to put a test target in your build file and specify this target in the job configuration, but I am using the build file generated by NetBeans, therefore if I modify it I assume it will just get overwritten.
My project is an enterprise application which is made of a single jar. The build script I am using is for the enterprise application, not the jar, so that an ear file is produced which I can then deploy to an application server.
Currently the build passes and produces and ear file which I can deploy and works, but nowhere in the console output does it show that it is running the tests.
The unit tests are in the jar project, so how can I get Jenkins to run the unit tests when it builds the ear file?
Question can be bit more clear - When your tests are executed ?
If your build runs the unit tests but not shown in the console, you should find a way to display it in console.
Like in Unix, executable run_qa_test > capture_results.txt - will capture all the results in the txt file and not display in console.
This can be modified as run_qa_test | tee capture_results.txt - This will display the output in console and record in txt file as well.
Or ,if you build produces ear file and if your tests in jar is not executed as part of the build job, you can create a new job as downstream of the build job and run those tests finally.
Or if needed to run only as part of the same build job you need to modify the build process
Let me explain some of my constraints.
We have a war that has a CXF Soap service and a Spring MVC REST Service. Both the CXF and Spring MVC implementations are in a separate jar and are brought in as dependencies. The REST service has its unit tests in its project.
I was wondering if there was any way to, while doing something like 'mvn clean test' in the REST jar, to have a local version of the war set up and then run the unit tests. Thus, when building in something like Hudson or doing releases, there won't have to be any workarounds (such as deploying a snapshot ear or running a local war manually)? I've seen this done when the tests are within the war using cargo, but not when the tests are separate from the war.
Right now, we're going to take the tests out into a separate jar but that's still not ideal as if something happens to go wrong during a release, that'd mean the REST jar and war were already released. I'd prefer do it the above way, with the tests in the same project as the REST service.
If anyone has any pointers or doc or examples that could help with this, it would be appreciated.
Honestly, I'm not sure I understood all the constraints. Anyway, the recommended way to implement integration tests with Maven is to put them in a separate module (that's much easier, especially if the module under test also have unit tests) that depends on the war/ear under test and to:
Start a container and deploy the war/ear during the pre-integration-test phase
Have Maven run the tests during integration-test
Stop the container during post-integration-test
For the steps #1 and #3, I personally use Cargo. For the step #2, using the Maven Failsafe Plugin is the preferred option (because it won't stop the build if a test fail). At least, this is what I use and I have used the resources below to build my setup.
An alternative approach would be to start/stop an embedded container from the tests. For example, this is doable with Jetty, see Embedding Jetty and Unit Test Servlets with Jetty.
Resources
Functional testing with Maven, Cargo and Selenium
Maven and Integration Testing
Maven and Selenium
Unit Test Servlets with Jetty
Maven has also integration-test phase. Use maven-jetty-plugin to start container and deploy application. Then run your integration test.
Maven Jetty Plugin
Maven and Integration Testing
Update
Tests cannot be in a jar file. Maven surefire plugin could not run them. The tests are part of the project where you run integration test. The tested war file can be set as dependency library. It will be downloaded, deployed and the you run integration tests.