spring-projects / spring-projects/spring-framework

Introduce `reason` attribute in `@DirtiesContext`

Open
#37,146 1 comment 0 reactions 1 assignee View on GitHub

@sbrannen is already working on this.

Since Aug 18, 2026.

in: test status: waiting-for-triage
Dominant language
Java
Stars
60.2k
Forks
38.8k
Avg merge
5d 2h
Merged PRs (30d)
27

Description

At Axelix, we sometimes use @DirtiesContext to test various cases where we need a fresh context.

Still, this annotation should be used wisely, since relying on it too much would cause tests to perform very slow - the context will just get recreated over and over again.

We have the pretty large monorepo where there are lots of Spring Boot tests, and we really try to make Spring Boot tests as efficient as possible. And we do not allow putting @DirtiesContext freely.

For example, we do not allow the usage of @DirtiesContext anywhere, unless there is a specific annotation called @IgnoreTestContextArchitecture that must articulate the reasoning on why this test requires @DirtiesContext (that annotation does more than this, but it is off-top).

Proposal:

The thought that crossed my mind: generally, it is a good idea to force people to think about the reason why they are using @DirtiesContext on the class. I think that not everybody understands the penalties that are caused by @DirtiesContext.

So, maybe it is worth adding an attribute to the @DirtiesContext annotation called reason, WDYT?

The very similar thing is done by Junit btw. In the @Disabled annotation, there is a value attribute, which also encompasses the reason on why this test is disabled.

Again, I'm not exactly sure whether this attribute should be required or not, but at very least, in my mind, it is worth adding. I'm more inclined to make it optional at least for now, and then we'll see how it goes.

Have a nice day, and big thanks to the Spring Team!

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.