IntelliJ 2018.1 issue with Spring Boot integration tests - spring-boot

I upgraded my IntelliJ version from 2017.3 to 2018.1 and now I can't run integration tests from the IDE anymore.
The project is a Spring Boot application and build with gradle. The integration tests look basically like this:
#RunWith(SpringRunner.class)
#SpringBootTest(
classes = TestApplication.class,
webEnvironment = SpringBootTest.WebEnvironment.NONE
)
#Transactional
public class MyServiceIT {
#Autowired
private MyService service;
#Test
public void test() {
// ...
}
}
It's still possible to run the test with gradle, but I can't run the isolated test from the IDE.
I get this error, because the instances cannot be autowired anymore:
[INFO] org.springframework.test.context.support.AbstractContextLoader - Could not detect default resource locations for test class [MyServiceIT]: no resource found for suffixes {-context.xml, Context.groovy}.
[INFO] org.springframework.boot.test.context.SpringBootTestContextBootstrapper - Loaded default TestExecutionListener class names from location [META-INF/spring.factories]: [org.springframework.boot.test.autoconfigure.restdocs.RestDocsTestExecutionListener, org.springframework.boot.test.autoconfigure.web.client.MockRestServiceServerResetTestExecutionListener, org.springframework.boot.test.autoconfigure.web.servlet.MockMvcPrintOnlyOnFailureTestExecutionListener, org.springframework.boot.test.autoconfigure.web.servlet.WebDriverTestExecutionListener, org.springframework.security.test.context.support.WithSecurityContextTestExecutionListener, org.springframework.boot.test.mock.mockito.MockitoTestExecutionListener, org.springframework.boot.test.mock.mockito.ResetMocksTestExecutionListener, org.springframework.test.context.web.ServletTestExecutionListener, org.springframework.test.context.support.DirtiesContextBeforeModesTestExecutionListener, org.springframework.test.context.support.DependencyInjectionTestExecutionListener, org.springframework.test.context.support.DirtiesContextTestExecutionListener, org.springframework.test.context.transaction.TransactionalTestExecutionListener, org.springframework.test.context.jdbc.SqlScriptsTestExecutionListener]
[INFO] org.springframework.boot.test.context.SpringBootTestContextBootstrapper - Using TestExecutionListeners: [org.springframework.test.context.web.ServletTestExecutionListener#309e345f, org.springframework.test.context.support.DirtiesContextBeforeModesTestExecutionListener#56a6d5a6, org.springframework.boot.test.autoconfigure.SpringBootDependencyInjectionTestExecutionListener#18ce0030, org.springframework.test.context.support.DirtiesContextTestExecutionListener#4445629, org.springframework.test.context.transaction.TransactionalTestExecutionListener#45b9a632, org.springframework.test.context.jdbc.SqlScriptsTestExecutionListener#25d250c6, org.springframework.security.test.context.support.WithSecurityContextTestExecutionListener#4df50bcc, org.springframework.boot.test.autoconfigure.restdocs.RestDocsTestExecutionListener#6b26e945, org.springframework.boot.test.autoconfigure.web.client.MockRestServiceServerResetTestExecutionListener#63a65a25, org.springframework.boot.test.autoconfigure.web.servlet.MockMvcPrintOnlyOnFailureTestExecutionListener#54c562f7, org.springframework.boot.test.autoconfigure.web.servlet.WebDriverTestExecutionListener#318ba8c8, org.springframework.boot.test.mock.mockito.MockitoTestExecutionListener#6dbb137d, org.springframework.boot.test.mock.mockito.ResetMocksTestExecutionListener#3c9d0b9d]
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name ...
I worked perfectly with version 2017.1. I think I have to change something in the IDEs configuration but I don't know what.
I'm using Windows 10, IntelliJ 2018.1, Java 1.8 and Spring Boot 1.5.10.RELEASE

Finally, I made it running again. In the Run/Debug Configurations the Working directory was set to $MODULE_DIR$. In my project that did not resolve correctly. After setting the Working directory explicitly to the project root, running specific integration tests worked.

In my experience, in a situation like this, where tests work with Gradle, but not in IntelliJ, it's most of the time because the classes are out of sync. This should be possible to fix by rebuilding the project:
Build -> Rebuild Project
In particularly tenacious cases it might help to additionally clear the caches:
File -> Invalidate Caches / Restart...

You may need to mark src/main/test as the "Test Sources Root".
https://www.jetbrains.com/help/idea/testing.html#add-test-root
Create a test root for your project
Follow these steps if you're building your project with the native
IntelliJ IDEA builder:
In the Project tool window (⌘ 1), right-click the directory in which you want to store your test code and select Mark Directory As |
Test Sources Root.
The tests folder should be marked with the the Tests root icon icon.

Related

How to pass spring.config.location="somepath" while building SpringBoot application with command-line Gradle (6.4) build

I have a SpringBoot application where I have application.properties file outside of project (it's not in usual place src/main/resources).
While building application with gradle clean build, it fails as code is not able to find properties files.
I have tried many command to pass vm args, gradle opts but its not working.
gradle clean build -Djvmargs="-Dspring.config.location=/users/home/dev/application.properties" //not working
It fails on test phase when it creates Spring application context and not able to substitute property placeholders. If I skip test as gradle clean build -x test it works.
Though I can run the app with java -jar api.jar --spring.config.location=file:/users/home/dev/application.properties
Please help how I can pass spring.config.location=/users/home/dev/application.properties in gradle build using command line so that build runs with all Junit tests
If I were you, I would not get involved the actual properties to junit test. So I would create a test properties for the project under src/test/resources/application-test.properties and in junit test I would load the test properties.
Example:
#RunWith(SpringRunner.class)
#SpringBootTest(classes = MyProperties.class)
#TestPropertySource("classpath:application-test.properties")
public class MyTestExample{
#Test
public void myTest() throws Exception {
...
}
}
System properties for running Gradle are not automatically passed on to the testing framework. I presume this is to isolate the tests as much as possible so differences in the environment will not lead to differences in the outcome, unless explicitly configured that way.
If you look at the Gradle API for the Test task, you can see that you can configure system properties through through the systemProperty method on the task (Groovy DSL):
test {
systemProperty "spring.config.location", "/path/to/my/configuration/repository/application.properties"
}
If you also want to read a system property from the Gradle command line and then pass that the test, you have to read it from Gradle first, e.g. as a project property, and then pass that value to the test:
test {
if (project.hasProperty('testconfig')) {
systemProperty 'spring.config.location', project.getProperty('testconfig')
}
}
Run it with gradle -Ptestconfig="/path/to/my/configuration/repository/application.properties" build
However, I would discourage using system properties on the build command line if you can avoid it. At the very least, it will annoy you greatly in the long run. If the configuration file can be in different locations on different machines (depending on where you have checkout out the repository and if it is not in the same relative path to your Spring Boot repository), you may want to specify it in a personal gradle.properties file instead.
I think there is a misunderstanding.
spring.config.location is used at runtime
As you validated:
java -jar api.jar --spring.config.location=file:/users/home/dev/application.properties
spring.config.location is used or required at runtime, not at build time.
When your spring boot app is building, an application.properties is required. An approach could be use an src/main/resources/application.properties with template values, but at runtime you will ignore it spring.config.location=file...
For unit tests
In this case as #nikos-bob said, you must use another properties, commonly inside of your src/test/resources
Environment variables instead external properties
We don't want to have hardcoded values in our main git repository src/main/resources/application.properties so the first idea is use an external properties. But this file must be stored in another git repository (equal to main repository ) or manually created.
Spring and other frameworks give us an alternative: Use environment variables.
So instead of manually external creation of application.properties or store it in our git repository, your spring boot app always must have an application.properties but with environment variables:
spring.datasource.url=jdbc:oracle:thin:#${DATABASE_HOST}:${DATABASE_PORT}:${DATABASE_SID}
spring.datasource.username=${DATABASE_USER}
spring.datasource.password=${DATABASE_PASSWORD}
spring.mail.host = ${MAIL_HOST}
spring.mail.username =${MAIL_USERNAME}
spring.mail.password =${MAIL_PASSWORD}
Advantages:
No manually creation of application.properties allowing us a more easy devops automations
No spring.config.location=file.. is required

JUnit class is not displayed in JMeter

I have created a Java project with 1 class containing 2 simple tests, exported as jar and added the jar in my JMeter JUnit folder, now after restarting the JMeter i don't see my class in JMeter even after selecting Annotation 4 option.
This is my class:
package print;
import org.junit.Test;
public class PrintClass {
#Test public void test() {
System.out.println("Hello World..!");
}
}
Consider the following checklist:
Your JUnit test class should have either empty constructor or constructor taking a single string as an argument. Other options are not supported
You should place your .jar file(s) under "lib/junit" folder of your JMeter installation
If there are any dependencies you need to put them somewhere in JMeter classpath as well
JMeter restart will be required to pick the .jars up
In case of any problems first of all check jmeter.log file (normally it lives under "bin" folder of your JMeter installation and contains enough troubleshooting information)
See How to Use JUnit With JMeter article for more details.
Even I faced same kind of issue then I added the dependency jars to the lib file.
Make sure you copy these files at this location -> apache-jmeter-5.1.1\lib
1.Selenium webdriver jar file (selenium-server-standalone)
2. Junit4 Jar file (junit4)
Make sure you add Jar file from eclipse or any IDE to this location -> apache-jmeter-5.1.1\lib\junit
1. Jar file which contains the automation selenium code (Using Junit)
Restart Jmeter and continue which the normal process of adding thread group and adding Junit sampler etc...
This resolved my issue and I was able to run my scripts on Jmeter.
In eclipse make sure that you create a JUnit class, not just the class and add junit annotations to this, even i was facing the same issue, it got resolved when i was created a JUnit class and then uploaded my project in JMeter
Did you put the jar in :
/lib/junit
Check you jar by running below command to see if it is ok:
jar -tvf <your jar>
And its dependencies as described in:
JUnit test classes not showing up in JMeter
See this for more details:
http://jmeter.apache.org/usermanual/junitsampler_tutorial.html

Spring Tools Suite and Gradle - Setup to use correct resources from inside STS

I have a Spring Boot Gradle project setup in Spring Tools Suite (3.7.2 RELEASE) with the following source folders:
- src/integration-test/java
- src/integration-test/resources
- src/main/java
- src/main/resources
- src/test/java
- src/test/resources`
Whenever I run the application or unit tests from within STS, I see that STS is using the resources found under src/integration-test/resources.
I see a duplicate resource warning in STS for files which exist in all 3 resource source folders. For example, I have an application.properties in all 3 source folders and I see following:
The resource is a duplicate of src/integration-test/resources/application.properties and was not copied to the output folder
If I run the application as a JAR or unit tests/integration tests from the command line (via gradle build), everything seems to use the correct resources. This makes me believe it is a problem with how STS/Eclipse is handling gradle.
Does anybody know of how I can configure STS to use the correct resource source folders when using gradle?
I think my problem may be related to (or the same as?) Spring Boot incorrectly loads test configuration when running from eclipse+gradle, https://issuetracker.springsource.com/browse/STS-3882, https://issues.gradle.org/browse/GRADLE-1777
I also tried the solution found here, but that seems to only fix Maven builds:
Spring Tool Suite finds spring-boot integration test configuration and does not start main application
I think my problem may be related to...
Yes, it is related but in my opinion not the same. That problem is caused by the runtime classpath being incorrect. This problem is an error coming from the eclipse project builder so it is a compile-time issue.
The problems are closely related though. Depending on your point of view, you could say they are the same (incorrect mixing of test and compile-time classpaths).
Here, specifically, the problem is that the eclipse builder tries to copy all the resources it finds in source folders to the project's single output folder. Each source folder has a 'application.properties'. The builder warns that it could not copy some of them because one would overwrite the other.
I think there may be a solution for this problem. But it is a solution that really should come from Gradle + ( BuildShip | STS Gradle Tooling) than from you.
It is possible in Eclipse to configure each source-folder individually to target a specific outputfolder. Maven + M2E are doing this correcty, but Gradle + (BuildsShip | STS Gradle Tooling) combdos do not.
For example this is what maven puts into the eclipse .classpath file when it configures a test resources folder:
<classpathentry excluding="**" kind="src" output="target/test-classes" path="src/test/resources">
<attributes>
<attribute name="maven.pomderived" value="true"/>
</attributes>
</classpathentry>
Notice how it explicitly sets the output folder for that entry (to something different from the project's default output folder).
You may be able to address the problem yourself by modifying the .classpath for a gradle project in a similar way. Either by doing it manually or from your build.gradle.
I'm not sure this is worth it however as you will then likely still get hit by the runtime classpath issue (since these folders will still be added to your runtime classpath, your runtime classpath will end-up with two appication.properties resources, one which will 'shadow' the other. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=482315)
I would say, the right thing to do is add a comment to the issue I linked, and hope they fix it soon as there is only so much you can do yourself by hacking the build.gradle file to modify the .classpath (this can not solve the runtime classpath issue, but in order to solve the runtime classpath issue, they would have to configure source folders to target individual output folder similar to what m2e does).
I would add this as a comment to #Kris's answer but it's too long.
I have solved the runtime classpath issue by adding the code below to my build.gradle file. The code generates an Eclipse launch configuration for the Spring Boot application class and includes only the runtime classpath (i.e. no test JARs).
My project uses the Gradle 'eclipse' plugin to generate the Eclipse project files (which I then import into Eclipse). Running the eclipseClasspath Gradle target will generate the launch file in the project's root directory.
def mainClassName = "com.example.MyApplication"
task eclipseApplicationLaunch {
group "IDE"
description "Generate an Eclipse launch configuration file for the Spring Boot application class"
}
eclipseApplicationLaunch << {
def writer = new FileWriter("${mainClassName.substring(mainClassName.lastIndexOf(".")+1)}.launch")
def xml = new groovy.xml.MarkupBuilder(writer)
xml.doubleQuotes = true
xml.launchConfiguration(type: "org.eclipse.jdt.launching.localJavaApplication") {
listAttribute(key:"org.eclipse.debug.core.MAPPED_RESOURCE_PATHS") {
listEntry(value:"/${project.name}/src/main/java/${mainClassName.replace(".","/")}.java")
}
listAttribute(key:"org.eclipse.debug.core.MAPPED_RESOURCE_TYPES") {
listEntry(value:"1")
}
listAttribute(key:"org.eclipse.jdt.launching.CLASSPATH") {
listEntry(value:"<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>\r\n<runtimeClasspathEntry containerPath=\"org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.8/\" javaProject=\"${project.name}\" path=\"1\" type=\"4\"/>\r\n")
listEntry(value:"<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>\r\n<runtimeClasspathEntry path=\"3\" projectName=\"${project.name}\" type=\"1\"/>\r\n")
configurations.runtime.resolvedConfiguration.resolvedArtifacts.each { artifact ->
def filePath = artifact.file.canonicalPath.replace("\\","/")
listEntry(value:"<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>\r\n<runtimeClasspathEntry externalArchive=\"${filePath}\" path=\"3\" type=\"2\"/>\r\n")
}
}
booleanAttribute(key:"org.eclipse.jdt.launching.DEFAULT_CLASSPATH", value:"false")
stringAttribute(key:"org.eclipse.jdt.launching.MAIN_TYPE", value:"${mainClassName}")
stringAttribute(key:"org.eclipse.jdt.launching.PROGRAM_ARGUMENTS", value:"--spring.profiles.active=local --spring.config.location=conf/")
stringAttribute(key:"org.eclipse.jdt.launching.PROJECT_ATTR", value:"${project.name}")
stringAttribute(key:"org.eclipse.jdt.launching.VM_ARGUMENTS", value:"-Djava.net.preferIPv4Stack=true")
}
writer.close()
}
eclipseClasspath.dependsOn eclipseApplicationLaunch
I haven't modified the Eclipse .classpath file as per Kris' suggestion. Instead, I have added #Profile("test") to my test application class and #ActiveProfiles("test") to my test classes.

Android Studio with Java Library Module Unable to load test resources

I have an Android Studio Project with a Java library inner module that has tests with test resources. Yet when i run the tests I am not able to retrieve the artifacts. This seems to work fine in a pure java gradle project (in eclipse at least).
meaning For java plugin:
src/main/java
src/main/test
src/test/java
src/test/resources
Under the resources directory i have a crt file that i want to load in my junit test. When using any command i have come across it returns null for the resource. Yet I have confirmed the resources are in the build folder.
Some things I Tried:
getClass().getClassLoader().getResourceAsStream("cert_format_der.crt").read(); // NPE
getClass().getClassLoader().getResourceAsStream("/cert_format_der.crt").read(); // NPE
getClass().getClassLoader().getSystemResourceAsStream("/cert_format_der.crt").read(); // NPE
Thanks
Turns out this seems to be a bug with Intellij and how Gradle not setting the resource directory for the test sourcesets correctly.
Adding This to the build.gradle for the module Fixes it:
sourceSets {
test {
output.resourcesDir = output.classesDir
}
}
Instead of diverging the resources to the class output directory − as suggested by nibbuen − it is also possible not to touch the output directory and explicitly add it as a dependency.
dependencies {
runtime files(sourceSets.test.output.resourcesDir)
}

maven spring test application contexts

I want to use the applicationContext.xml in my src/main/resources directory from within my test harness in src/test/java. How do I load it? I have tried:
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(locations="classpath:applicationContext.xml")
public class TestService {
...
}
but get a file not found error. I'm using Maven and Spring. Thanks.
Try this (note the asterisk):
#ContextConfiguration("classpath*:applicationContext.xml")
The Maven test classpath uses the files in target/test-classes. That folder contains Java classes from src/test/java and resources from src/test/resources.
The way to go is to create a test specific app context and store it under src/main/resources.
You may try to reference the file directly using file: i.e. something like file:src/main/resources/applicationContext.xml but to me this is an ugly hack.
Also, you can of course use the Maven resources plugin to copy applicationContext.xml prior to test execution.
Here's how I do it, it may or may not be the best way for you. The main thing is it works in both Eclipse and Maven:
Keep exactly one copy of each applicationContext-xxx.xml file per project. NEVER copy-and-paste them or their contents, it'll create a maintenance nightmare.
Externalize all environmental settings to properties files (e.g. database-prod.properties and database-test.properties) and place them in src/main/resources and src/test/resources respectively. Add this line to your app contexts:
<context:property-placeholder location="classpath:**/*.properties"/>
Create a superclass for all test classes and annotate it with a context configuration:
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(locations = {"classpath:applicationContext.xml"})
#Ignore
public class SpringEnabledTest {
// Inheritable logger
protected Logger logger = LoggerFactory.getLogger(this.getClass());
}
Add <additionalClasspathElements> to your maven-surefire-plugin configuration to make sure surefire picks up appContext and the right properties files. I've created an example here.
Add the location(s) of the app context files and src/test/resources to your Eclipse classpath so you can execute unit tests in Eclipse as well.
NEVER add src/main/resources to your Eclipse classpath, it's only a convenient place for Maven to package additional source files, it should have no bearing on Eclipse. I often leave this directory blank and create additional folders (e.g. env/DEV, env/UAT and env/PROD) outside of the src/ folder and pass a parameter to the build server and let it know from which folder it needs to copy files to src/main/resources.
Add the src folder to the classpath of your testing tool. If it's in Eclipse, I think you can do it from the project properties. You may have to change it to classpath:**/applicationContext.xml as well.

Resources