I am trying out spring's java configuration. While using xml config files my unit tests use to have the following
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(....)
If I am using java configuration, How do i do it. or should I just use
ApplicationContext appConfig = new AnnotationConfigApplicationContext(SimpleConfiguration.class);
As of Spring 3.1, #ContextConfiguration now has full support for #Configuration classes; no XML required.
See http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/htmlsingle/spring-framework-reference.html#d0e1392
Or more specifically, http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/htmlsingle/spring-framework-reference.html#testcontext-ctx-management-javaconfig, which shows the following code snippet:
#RunWith(SpringJUnit4ClassRunner.class)
// ApplicationContext will be loaded from AppConfig and TestConfig
#ContextConfiguration(classes={AppConfig.class, TestConfig.class})
public class MyTest {
// class body...
}
AppConfig and TestConfig are #Configuration classes (aka "Java config" classes in #user373201's comments)
#ContextConfiguration is used to load the Spring configurations while you are working with test cases . If you don't need it , you could use ClassPathXmlApplicationContext to load the Spring configuration .
Use the constructor which takes in configuration locations as String array .
AnnotationConfigApplicationContext is used to auto detect the annotated classes . I don't think it can be used to load configuration files . It is similar to context:component-scan
SpringJUnit4ClassRunner provides Spring Test support for Junit via annotations like #Test.
Related
I am new to Spring and spring boot.
For my spring boot application which is a rest controller, I have some beans along with my data source.
I use my data source to create jdbc template. Now when I am in my rest controller code, I have all these beans #Autowired and they work perfectly fine.
My query is regarding the junit testing part.
When I write my test code inside src/test/java and when I execute my test class within IDE, are the beans defined in my src/main/javacode, instantiated before test case execution?
You might use the same container, or instantiate another container particularly for testing purposes, for which you'll provide a configuration of that other Spring Container separately:
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration("classpath:test-context.xml")
public class SomeClassTest{...}
However, you can also enable support for loading your Application Context and then use the #Autowired fields in your JUnit fixtures, which also works fine too:
#RunWith(SpringRunner.class)
public class SomeTestClass {
....
#Autowired
ApplicationContext context;
....
}
From here, you can get any bean you wish.
Assume we have Spring Boot application and want to load only specific slice of application context.
Particularly load YAML file configuration and map spring.datasource to DataSourceProperties marked by #ConfigurationProperties.
Naive not working declaration of test is:
#RunWith(SpringRunner.class)
#ContextConfiguration(
classes = {DataSourceAutoConfiguration.class, DataSourceProperties.class},
loader = AnnotationConfigContextLoader.class,
initializers = ConfigFileApplicationContextInitializer.class)
#TestPropertySource({"classpath:application.yaml", "classpath:application-dev.yaml"})
#EnableConfigurationProperties({DataSourceProperties.class})
#Slf4j
public class HibernateTest {
#Autowired
private DataSourceProperties dataSourceProperties;
#Test
public void dataSourceTest() throws SQLException {
log.info("DS URL: {}", dataSourceProperties.getUrl());
}
}
application-dev.yaml has:
spring.datasource:
url: jdbc:oracle:thin:#localhost:1521/APP
Test prints:
DS URL: null
I am looking for a way to map YAML config to #ConfigurationProperties marked class (DataSourceProperties) and make it used by #Configuration class (DataSourceAutoConfiguration) without loading any other services/components/etc...
Those links answer my questions:
https://jira.spring.io/browse/SPR-13912
Add support for YAML files to #PropertySource (Resolution: Unresolved).
https://jira.spring.io/browse/SPR-16563
Document that #PropertySource and #TestPropertySource do not support YAML.
https://github.com/spring-projects/spring-boot/issues/12388
Property Override not Working For YML Files.
https://github.com/spring-projects/spring-boot/issues/10772
Map properties in yaml from TestPropertySource not working in boot 2.0.0.
In short Spring Framework developers don't want to support YAML format for #TestPropertySource & #PropertySource annotation explaining that YAML support in Spring Boot made in tricky way / broken way (though I lost in explanations).
After switching code to use .properties files my test works fine.
I have a multi-module Spring-Boot project.
I was wondering how I can set up integration testing just to test Spring Data JPA repositories? The following approach fails with this exception:
HV000183: Unable to load 'javax.el.ExpressionFactory'. Check that you have the EL dependencies on the classpath.
Since this module does not depend on the web module, there is no web application that can be started.
#RunWith(SpringJUnit4ClassRunner.class)
#IntegrationTest
#SpringApplicationConfiguration(classes = TestConfiguration.class)
class CardInfoRepositoryIT {
#Autowired CardInfoRepository cardInfoRepository;
#Test
void testLoadData() {
assert cardInfoRepository.findAll().size() == 1
}
}
As Marten mentioned, #IntegrationTest should only be used when you need to test against the deployed Spring Boot application (e.g., deployed in an embedded Tomcat, Jetty, or Undertow container). So if your goal is to test your repository layer in isolation, you should not use #IntegrationTest.
On the other hand, if your tests require specific Spring Boot functionality (in contrast to standard Spring Framework functionality, semantics, and defaults), then you will in fact want to annotate your test class with #SpringApplicationConfiguration instead of #ContextConfiguration. The reason is that #SpringApplicationConfiguration preconfigures the SpringApplicationContextLoader which is specific to Spring Boot.
Furthermore, if you want your repository layer integration tests to run faster (i.e., without the full overhead of Spring Boot), you may choose to exclude configuration classes annotated with #EnableAutoConfiguration since that will auto-configure every candidate for auto-configuration found in the classpath. So, for example, if you just want to have Spring Boot auto-configure an embedded database and Spring Data JPA (with Hibernate as the JPA provider) along with entity scanning, you could compose your test configuration something like this:
#Configuration
#EnableJpaRepositories(basePackageClasses = UserRepository.class)
#EntityScan(basePackageClasses = User.class)
#Import({ DataSourceAutoConfiguration.class, HibernateJpaAutoConfiguration.class })
public class TestRepositoryConfig {}
And then use that configuration in your test class like this:
#RunWith(SpringJUnit4ClassRunner.class)
#SpringApplicationConfiguration(classes = TestRepositoryConfig.class)
#Transactional
public class UserRepositoryTests { /* ... */ }
Regards,
Sam
p.s. You might find my answer to the following, related question useful as well: Disable security for unit tests with spring boot
I resolved this by having the following test config class.
#Configuration
#EnableAutoConfiguration
#ComponentScan
#PropertySource("classpath:core.properties")
class TestConfiguration {
}
core.properties is also used by the main application and it contains datasource information. #IntegrationTest annotation can be removed on the test class.
I also added the following to the module as dependencies:
testRuntime 'javax.el:javax.el-api:2.2.4'
testRuntime 'org.glassfish.web:javax.el:2.2.4'
I'm writing integration tests with SpringJUnit4. I got question. How in #ContextConfiguration I can use XML based config and Java-based at same time. As I know I couldn't do it, but maybe there exist backdoor?
Thanks in advance!
You could create static inner #Configuration class in your test class and use #ContextConfiguration annotation on your class without any parameters. As stated in the article below, Spring will automatically look for static inner #Configuration class if no XML locations or config classes are passed to the annotation.
You can then import your XML config and Java config classes using #Import and #ImportResource annotations. So your base class for your Spring tests could look something like this:
#ContextConfiguration
#RunWith(SpringJUnit4ClassRunner.class)
public class BaseSpringTest {
#Configuration
#Import(BaseConfig.class)
#ImportResource({ "classpath:applicationContext-hibernate.xml" })
public static class ContextConfig {}
}
Sources
Testing with #Configuration Classes and Profiles
Import annotation JavaDoc
ImportResource annotation JavaDoc
Use #ImportResource on #Configuration class to import XML based config.
What does this annotation do?
When would I want to use it?
When would I not want to use it?
#RunWith(SpringJUnit4ClassRunner.class)
I can find more usages of this when I Google and do not find a 101 explanation as to what this annotation is supposed to communicate to me or when/why I would use it?
The annotation is used to configure a unit test that required Spring's dependency injection.
From Spring Reference - 10. Unit Testing:
10.1 Creating a Unit Test Class
In order for the unit test to run a batch job, the framework must load the job's ApplicationContext. Two annotations are used to trigger this:
#RunWith(SpringJUnit4ClassRunner.class): Indicates that the class should use Spring's JUnit facilities.
#ContextConfiguration(locations = {...}): Indicates which XML files contain the ApplicationContext.
If you are using annotations rather than XML files, then any class that you are unit testing that requires Spring dependency injection needs to be put into the #ContextConfiguration annotation. For example:
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(classes = FooManager.class)
class FooManagerTest {
#Autowired
FooManager fooManager;
Now when you use fooManager in a unit test it will have have a Spring context setup for it.
If fooManager autowires in any beans then those bean's classes also need to be in the #ContextConfiguration annotation. So if fooManager autowires in a FooReporter bean:
#ContextConfiguration(classes = {FooManager.class, FooReporter.class})
If the beans that fooManager autowires in contain state, then you will likely want to reset the state of those beans for each test. In that case you can add the #DirtiesContext annotation to your test class:
#DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD)
If fooManager or any of its autowired beans reads Spring config then you need to add an initializers list to the #ContextConfiguration annotation, that contains the ConfigFileApplicationContextInitializer class:
#ContextConfiguration(classes = {FooManager.class, FooReporter.class}, initializers = ConfigFileApplicationContextInitializer.class)
To answer the when you would and wouldn't want to use it part of the question.
When to use SpringJUnit4ClassRunner
IMO SpringJUnit4ClassRunner should be used very sparingly. There is a significant overhead involved with starting up a Spring container to run a unit test.
I typically use SpringJUnit4ClassRunner to test:
that components are injected (auto-wired) as expected
that configuration data is injected as expected
When you are injecting components issues can arise if the #Qualifier annotation is not used or used incorrectly, for example.
When loading configuration from multiple yaml files you may want to test that maps are being merged as expected, with the appropriate overrides occurring.
At the very least I always have a simple SpringJUnit4ClassRunner test as a sanity check that the Spring container starts up OK.
When not to use SpringJUnit4ClassRunner
I would not use SpringJUnit4ClassRunner to test the non-Spring related functionality in my code under test. Which in my experience means most of the functionality.
So this means that any autowired components and injected config data needs to be mocked. This can mean quite a bit of setup code for your unit tests. However this setup code only needs to be written once for all the tests in your class under test. It is also much quicker to run unit tests with mocked components.
I keep the mocking simple and use Spock to mock the components. Example groovy code:
import spock.lang.Specification
class FooManagerTest extends Specification {
FooManager cut
void createMockFooReporter() {
FooReporter mockFooReporter = Mock(FooReporter)
mockFooReporter.fooFormatter = Mock(FooFormatter)
}
void setup() {
cut = new FooManager()
cut.fooReporter = createMockFooReporter()
}
void "Basic test"() {
// Do a basic test using 'cut'
}
}
In this example the class under test FooManager has an autowired FooReporter which itself contains an autowired FooFormatter.
I think #RunWith annotation is in order to initialize the context of spring. Because the junit5 is released, you just can replace it with #SpringJUnitConfig.By the way, #RunWith annotation is already replaced by #ExtendWith, but you still can use it.