I have 3 modules in my gradle project: 1. Main, Test (Unit tests), 3. IntegrationTest
I added testImplementation for flyway migrations to be used in the integration tests, then I've created resources folder for this module and put my migration script inside resources/db/migration.
And then, when I try to run tests inside I have this exception:
Entry db.migration/V1__schema.sql is a duplicate but no duplicate handling strategy has been set.
It seems like complete nonsense for me
Related
Added Spring Cloud Contract plugin and configured it for baseClassMappings
Added Spring Cloud Contract verifier
Added required base classes for generated tests
Defined groovy contract
Using Test{useunitPlatform()} to identify and execute the JUnit tests
The contract tests are getting generated in the build/generated-test-sources but not being executed. I'm getting build successful without these contract tests being executed.
I'm using gradle 7.4 version and junit-jupiter-engine version 5.7.0.
I also had this problem in the past. I however solved it in maven since my project runs with that. There might be similar configuration properties in gradle. You can manually ride the configuration and in which files to look at.
<configuration>
<contractsRepositoryUrl>http://yourContractsRepositoryUrl.com</contractsRepositoryUrl>
<!-- We want to use the JAR with contracts with the following coordinates -->
<contractDependency>
<groupId>org.example</groupId>
<artifactId>example-artifact</artifactId>
<classifier>stubs</classifier>
</contractDependency>
<!-- The JAR with contracts should be taken from Maven remote -->
<contractsMode>REMOTE</contractsMode>
<includedFiles>
<includedFile>*filennameA*</includedFile>
<includedFile>*filennameB*</includedFile>
</includedFiles>
<contractsPath>your.contracts.package.structure</contractsPath>
<baseClassForTests>
org.someservice.contracts.ContractVerifierBase
</baseClassForTests>
<basePackageForTests>org.someservice.contracts
</basePackageForTests>
<testFramework>JUNIT5</testFramework>
I hope that there is an approach in there for you. It always unpleasant to get the contracts to run in my experience :(
This issue got resolved with these changes in my case:
I added this dependency group: 'org.junit.platform', name:'junit-platform-runner', version: '1.7.0' inside testImplementation in rest/build.gradle.
useJUnitPlatform() instead of useJUnit() in test section in rest/build.gradle
Changed the #RunWith(SpringRunner.class), to #RunWith(JUnitPlatform.class) in all the BaseClasses
Replaced the #Before with #BeforeEach in all the baseclasses.
Deleting .gradle and build temporary folders and rebuilding/regenerating sources helped me
I have a microservice that has a sub-folder full of integration tests written in Groovy. These tests basically make a bunch of REST calls. Gradle is configured to produce a JAR for these tests like so:
//Explicitly add the integration tests to the JAR
jar {
from sourceSets.test.output
}
Unzipping the JAR shows the Groovy tests that were in the project. That seems good so far.
Now, there is a larger project that I want to use (in a different git repo) that will import these tests and run them. The plan is to import several other test suites in a similar fashion and build a sort of uber-test project. This project can import the test JAR as a dependency as testCompile. I can see the JAR in the SourceSets using IDEA's gradle plugin. However, I can't get the tests to run using gradle test.
How can I modify the uber-test project to execute these imported test?
I am running a set of tests using junit and I have created a maven project for it. I use the surefire plugin to run the tests. I wanted to package this project as a self executable jar for the sake of convenience.So I placed all of test classes in the src/main/java directory as recommended for using the maven shade plugin for generating an uber jar. I created a class with a main method and use maven invoker to execute my tests.
The tests get executed perfectly when I use my ide to run the main method. However, after I package it as a jar , the invoker is unable to locate the pom.xml. If I place a copy of the pom.xml in the same directory as the jar, maven is invoked but it is unable to execute the tests as surefire is unable to locate the tests.
I would love to know if there is a solution for this or if there is a better approach towards trying to achieve my goal.
#khmarbaise and everyone else trying to help me , let me describe my scenario a little more in detail.
Lets take any api , for example , lastfm api, I would be writing classes for each api end point and every method in each class would be a test. I use junit to execute the tests. I use a junit wrapper called serenity bdd that helps me structure my tests and generate aggregate reports. The maven goal serenity:aggregate would generate an aggregated report of all tests. I am using the maven invoker to run tests using surefire plugin and then aggregate the tests using serenity. In my eclipse project I simply create a maven run configuration and provide the maven goals. Or else I would use the terminal to run maven from my project base directory.
Apart from my class file, I have several resources, like csv files which are inputs for parametric tests a log folder where all log files that are generated get saved and other sample files for testing file upload apis. I felt that it would be simple to package all of this as a jar and let my developers add this jar as a dependency and run a simple script which runs the jar each time they create and deploy a build. Getting the pom file for invoking maven was trivial in case of eclipse or the command line but not so straight forward when its inside of a package.
I've created a project with several gradle subprojects, including: "app" and "tests".
Tests have "app" in their dependencies. Tests use classes from "app"
When I run:
./gradlew clean test build
Everything works, tests run and pass.
But when I run:
./gradlew clean build
then the tests compilation fails with an error saying that a class is missing - in this case it's a spring-boot configuration class. I run this with --debug and it turns out that in the failing case app:bootRepackage task is executed before tests:test, the jar generated by app compilation is altered and that's why the classes cannot be found.
How can I make "./gradlew clean build" work properly?
Using: spring-boot 1.5, gradle 4.0 (and 4.1 too), io.spring.dependency-management plugin 1.0.0.RELEASE
Ideally, you shouldn't use a Spring Boot application (something that's been repackaged) as a dependency. From the documentation:
Like a war file, a Spring Boot application is not intended to be used as a dependency. If your application contains classes that you want to share with other projects, the recommended approach is to move that code into a separate module. The separate module can then be depended upon by your application and other projects.
If the proposed solution isn't possible in your situation, the documentation goes on to describe an alternative:
If you cannot rearrange your code as recommended above, Spring Boot’s Maven and Gradle plugins must be configured to produce a separate artifact that is suitable for use as a dependency. The executable archive cannot be used as a dependency as the executable jar format packages application classes in BOOT-INF/classes. This means that they cannot be found when the executable jar is used as a dependency.
To produce the two artifacts, one that can be used as a dependency and one that is executable, a classifier must be specified. This classifier is applied to the name of the executable archive, leaving the default archive for use as dependency.
To configure a classifier of exec … when using Gradle, the following configuration can be used:
bootRepackage {
classifier = 'exec'
}
I am trying to understand the maven build lifecycle when it is regarding to tests:
Let's say I have a project with a class in the src/main folder and another one in the src/test. When I run mvn install, it get's compiled, then tested, then packaged and installed.
Until now I thought that maven would not package the tests in the snapshot, because this is not "production" code. Is this true?
In this case, when does maven ignores the test files?
What you said about the Maven lifecycle is true. The "main" phases include:
compile: in this phase, the maven-compiler-plugin:compile goal is run which compiles the main code of the project.
test-compile: in this phase, the maven-compiler-plugin:testCompile goal is run which compiles the test code of the project.
test: in this phase, the maven-surefire-plugin:test goal is run and all the unit tests are executed.
package: in this phase, the maven-jar-plugin:jar goal is run and creates a JAR of the current project. By default, this JAR will include all classes under target/classes, which contains all the main classes, but not the test classes which are located inside target/test-classes. You could say that it is at this step that Maven ignores the test classes.
install: in this phase, the maven-install-plugin:install will install the main artifact, and every attached artifact, into your local repository.
To answer more precisely, it's not that Maven ignores the test classes, it is that by default, the packaging process only considers the main classes. But you can configure it to also package the test classes with the maven-jar-plugin:test-jar goal inside another attached artifact.