Master the most popular testing framework for Java, through the Learn JUnit course:
Mocking is an essential part of unit testing, and the Mockito library makes it easy to write clean and intuitive unit tests for your Java code.
Get started with mocking and improve your application tests using our Mockito guide:
Handling concurrency in an application can be a tricky process with many potential pitfalls. A solid grasp of the fundamentals will go a long way to help minimize these issues.
Get started with understanding multi-threaded applications with our Java Concurrency guide:
Spring 5 added support for reactive programming with the Spring WebFlux module, which has been improved upon ever since. Get started with the Reactor project basics and reactive programming in Spring Boot:
Since its introduction in Java 8, the Stream API has become a staple of Java development. The basic operations like iterating, filtering, mapping sequences of elements are deceptively simple to use.
But these can also be overused and fall into some common pitfalls.
To get a better understanding on how Streams work and how to combine them with other language features, check out our guide to Java Streams:
Get started with Spring and Spring Boot, through the Learn Spring course:
>> LEARN SPRINGExplore Spring Boot 3 and Spring 6 in-depth through building a full REST API with the framework:
Yes, Spring Security can be complex, from the more advanced functionality within the Core to the deep OAuth support in the framework.
I built the security material as two full courses - Core and OAuth, to get practical with these more complex scenarios. We explore when and how to use each feature and code through it on the backing project.
You can explore the course here:
Spring Data JPA is a great way to handle the complexity of JPA with the powerful simplicity of Spring Boot.
Get started with Spring Data JPA through the guided reference course:
Refactor Java code safely β and automatically β with OpenRewrite.
Refactoring big codebases by hand is slow, risky, and easy to put off. Thatβs where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.
Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions β one for newcomers and one for experienced users. Youβll see how recipes work, how to apply them across projects, and how to modernize code with confidence.
Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.
1. Overview
In this article, weβll explore the @WebAppConfiguration annotation in Spring, why we need it in our integration tests and also how can we configure it so that these tests actually bootstrap a WebApplicationContext.
2. @WebAppConfiguration
Simply put, this is a class-level annotation used to create a web version of the application context in the Spring Framework.
Itβs used to denote that the ApplicationContext which is bootstrapped for the test should be an instance of WebApplicationContext.
A quick note about usage β weβll usually find this annotation in integration tests because the WebApplicationContext is used to build a MockMvc object. You can find more information about integration testing with Spring here.
3. Loading a WebApplicationContext
Starting with Spring 3.2, there is now support for loading a WebApplicationContext in integration tests:
@WebAppConfiguration
@ContextConfiguration(classes = WebConfig.class)
public class EmployeeControllerTest {
...
}
This instructs the TestContext framework that a WebApplicationContext should be loaded for the test.
And, in the background a MockServletContext is created and supplied to our testβs WebApplicationContext by the TestContext framework.
3.1. Configuration Options
By default, the base resource path for the WebApplicationContext will be set to βfile:src/main/webappβ, which is the default location for the root of the WAR in a Maven Project.
However, we can override this by simply providing an alternate path to the @WebAppConfiguration annotation:
@WebAppConfiguration("src/test/webapp")
We can also reference a base resource path from the classpath instead of the file system:
@WebAppConfiguration("classpath:test-web-resources")
3.2. Caching
Once the WebApplicationContext is loaded it will be cached and reused for all subsequent tests that declare the same unique context configuration within the same test suite.
For further details on caching, you can consult the Context caching section of the reference manual.
4. Using @WebAppConfiguration in Tests
Now that we understand why do we need to add the @WebAppConfiguration annotation in our test classes, letβs see what happens if we miss adding it when we are using a WebApplicationContext.
@RunWith(SpringJUnit4ClassRunner.class)
// @WebAppConfiguration omitted on purpose
@ContextConfiguration(classes = WebConfig.class)
public class EmployeeTest {
@Autowired
private WebApplicationContext webAppContext;
private MockMvc mockMvc;
@Before
public void setup() {
MockitoAnnotations.initMocks(this);
mockMvc = MockMvcBuilders.webAppContextSetup(webAppContext).build();
}
...
}
Notice that we commented out the annotation to simulate the scenario in which we forget to add it. Here itβs easy to see why the test will fail when we run the JUnit test: we are trying to autowire the WebApplicationContext in a class where we havenβt set one.
A more typical example however is a test that uses a web-enabled Spring configuration; thatβs actually enough to make the test break.
Letβs have a look:
@RunWith(SpringJUnit4ClassRunner.class)
// @WebAppConfiguration omitted on purpose
@ContextConfiguration(classes = WebConfig.class)
public class EmployeeTestWithoutMockMvc {
@Autowired
private EmployeeController employeeController;
...
}
Even though the above example isnβt autowiring a WebApplicationContext it will still fail because itβs trying to use a web-enabled configuration β WebConfig:
@Configuration
@EnableWebMvc
@ComponentScan("com.baeldung.web")
public class WebConfig implements WebMvcConfigurer {
...
}
The annotation @EnableWebMvc is the culprit here β that will basically require a web enabled Spring context, and without it β weβll see the test fail:
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException:
No qualifying bean of type [javax.servlet.ServletContext] found for dependency:
expected at least 1 bean which qualifies as autowire candidate for this dependency.
Dependency annotations:
{@org.springframework.beans.factory.annotation.Autowired(required=true)}
at o.s.b.f.s.DefaultListableBeanFactory
.raiseNoSuchBeanDefinitionException(DefaultListableBeanFactory.java:1373)
at o.s.b.f.s.DefaultListableBeanFactory
.doResolveDependency(DefaultListableBeanFactory.java:1119)
at o.s.b.f.s.DefaultListableBeanFactory
.resolveDependency(DefaultListableBeanFactory.java:1014)
at o.s.b.f.a.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement
.inject(AutowiredAnnotationBeanPostProcessor.java:545)
... 43 more
So thatβs the problem that weβre easily fixing by adding the @WebAppConfiguration annotation to our tests.
5. Conclusion
In this article we showed how we can let the TestContext framework to load a WebApplicationContext into our integration tests just by adding the annotation.
Finally, we looked at the examples that even though if we add the @ContextConfiguration to the test, this wonβt be able to work unless we add the @WebAppConfiguration annotation.
