Expand Authors Top

If you have a few years of experience in the Java ecosystem and you’d like to share that with the community, have a look at our Contribution Guidelines.

Expanded Audience – Frontegg – Security (partner)
announcement - icon User management is very complex, when implemented properly. No surprise here.

Not having to roll all of that out manually, but instead integrating a mature, fully-fledged solution - yeah, that makes a lot of sense.
That's basically what Frontegg is - User Management for your application. It's focused on making your app scalable, secure and enjoyable for your users.
From signup to authentication, it supports simple scenarios all the way to complex and custom application logic.

Have a look:

>> Elegant User Management, Tailor-made for B2B SaaS

NPI – Spring Top – Temp – Non-Geo (Lightrun)

Get started with Spring 5 and Spring Boot 2, through the reference Learn Spring course:

>> LEARN SPRING
NPI – Lightrun – Spring (partner)

We rely on other people’s code in our own work. Every day. It might be the language you’re writing in, the framework you’re building on, or some esoteric piece of software that does one thing so well you never found the need to implement it yourself.

The problem is, of course, when things fall apart in production - debugging the implementation of a 3rd party library you have no intimate knowledge of is, to say the least, tricky. It’s difficult to understand what talks to what and, specifically, which part of the underlying library is at fault.

Lightrun is a new kind of debugger.

It's one geared specifically towards real-life production environments. Using Lightrun, you can drill down into running applications, including 3rd party dependencies, with real-time logs, snapshots, and metrics. No hotfixes, redeployments, or restarts required.

Learn more in this quick, 5-minute Lightrun tutorial:

>> The Essential List of Spring Boot Annotations and Their Use Cases

1. Overview

In this quick tutorial, we'll learn about the @DirtiesContext annotation. We'll also show a standard way to use the annotation for testing.

2. @DirtiesContext

@DirtiesContext is a Spring testing annotation. It indicates the associated test or class modifies the ApplicationContext. It tells the testing framework to close and recreate the context for later tests.

We can annotate a test method or an entire class. By setting the MethodMode or ClassMode, we can control when Spring marks the context for closure.

If we place @DirtiesContext on a class, the annotation applies to every method in the class with the given ClassMode.

3. Testing Without Clearing the Spring Context

Let's say we have a User:

public class User {
    String firstName;
    String lastName;
}

We also have a very simple UserCache:

@Component
public class UserCache {

    @Getter
    private Set<String> userList = new HashSet<>();

    public boolean addUser(String user) {
        return userList.add(user);
    }

    public void printUserList(String message) {
        System.out.println(message + ": " + userList);
    }

}

We create an integration test to load up and test the full application:

@TestMethodOrder(OrderAnnotation.class)
@ExtendWith(SpringExtension.class)
@SpringBootTest(classes = SpringDataRestApplication.class)
class DirtiesContextIntegrationTest {

    @Autowired
    protected UserCache userCache;
    
    ...
}

The first method, addJaneDoeAndPrintCache, adds an entry to the cache:

@Test
@Order(1)
void addJaneDoeAndPrintCache() {
    userCache.addUser("Jane Doe");
    userCache.printUserList("addJaneDoeAndPrintCache");
}

After adding a user to the cache, it prints the contents of the cache:

addJaneDoeAndPrintCache: [Jane Doe]

Next, printCache prints the user cache again:

@Test
@Order(2)
void printCache() {
    userCache.printUserList("printCache");
}

It contains the name added in the previous test:

printCache: [Jane Doe]

Let's say a later test was relying on an empty cache for some assertions. The previously inserted names may cause undesired behavior.

4. Using @DirtiesContext

Now we'll show @DirtiesContext with the default MethodModeAFTER_METHOD. This means Spring will mark the context for closure after the corresponding test method completes.

To isolate changes to a test, we add @DirtiesContext. Let's see how it works.

The addJohnDoeAndPrintCache test method adds a user to the cache. We have also added the @DirtiesContext annotation, which says the context should shut down at the end of the test method:

@DirtiesContext(methodMode = MethodMode.AFTER_METHOD)
@Test
@Order(3)
void addJohnDoeAndPrintCache() {
    userCache.addUser("John Doe");
    userCache.printUserList("addJohnDoeAndPrintCache");
}

The output is now:

addJohnDoeAndPrintCache: [John Doe, Jane Doe]

Finally, printCacheAgain prints the cache again:

@Test
@Order(4)
void printCacheAgain() {
    userCache.printUserList("printCacheAgain");
}

Running the full test class, we see the Spring context reload in between addJohnDoeAndPrintCache and printCacheAgain. So the cache reinitializes, and the output is empty:

printCacheAgain: []

5. Other Supported Test Phases

The example above shows the after current test method phase. Let's do a quick summary of the phases:

5.1. Class Level

The ClassMode options for a test class define when the context is reset:

  • BEFORE_CLASS: Before current test class
  • BEFORE_EACH_TEST_METHOD: Before each test method in the current test class
  • AFTER_EACH_TEST_METHOD: After each test method in the current test class
  • AFTER_CLASS: After the current test class

5.2. Method Level

The MethodMode options for an individual method define when the context is reset:

  • BEFORE_METHOD: Before the current test method
  • AFTER_METHOD: After the current test method

6. Conclusion

In this article, we presented the @DirtiesContext testing annotation.

As always, the example code is available over on GitHub.

Spring bottom

Get started with Spring 5 and Spring Boot 2, through the Learn Spring course:

>> THE COURSE
Junit footer banner
Comments are closed on this article!