@TempDir field in super class skipped when it has same name as a @TempDir field in subclass

[sbrannen]

Overview

After fixing #3498, I realized that the same types of bugs exist for finding fields in a type hierarchy.

The fix for fields should be analogous to the fix for methods: apply field predicate before searching type hierarchy.

Example

SuperclassTempDirTests passes, but SubclassTempDirTests fails unless you rename one of the @TempDir fields to something other than tempDir.

package demo.a;

import static org.assertj.core.api.Assertions.assertThat;

import java.nio.file.Path;

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.io.TempDir;

public class SuperclassTempDirTests {

	@TempDir
	static Path tempDir;

	protected static Path getStaticTempDir() {
		return tempDir;
	}

	@Test
	void superTest() {
		assertThat(getStaticTempDir()).exists();
	}

}

package demo.b;

import static org.assertj.core.api.Assertions.assertThat;

import java.nio.file.Path;

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.io.TempDir;

import demo.a.SuperclassTempDirTests;

class SubclassTempDirTests extends SuperclassTempDirTests {

	@TempDir
	Path tempDir;

	Path getInstanceTempDir() {
		return this.tempDir;
	}

	@Test
	void subTest() {
		assertThat(getInstanceTempDir()).exists();
		assertThat(getStaticTempDir()).exists();
	}

}

Related Issues

• @BeforeAll method in super class skipped when it has same name as a @BeforeEach method in subclass #3498

Deliverables

• Apply field predicate before searching type hierarchy.

[sbrannen]

Tentatively slated for inclusion in 5.10.1; however, if we don't have time to fix it before the release, we may decide to postpone the fix for a subsequent 5.10.x or the 5.11.0 release.

@marcphilipp, I've already submitted PR #3533 (which contains some TODOs), but if I don't complete it before you release 5.10.1 perhaps you can take it over.

[sbrannen]

• see PR Apply field predicate before searching type hierarchy #3533

[sbrannen]

This has been merged into main and backported to 5.10.x.

[Marcono1234]

Out of curiosity (not because my tests currently do this), this only covers the case where one field is static and the other one is non-static, right?
Adjusting your example so that either both fields are static or both are non-static seems to still fail in 5.10.1.

[sbrannen]

Hi @Marcono1234,

Out of curiosity (not because my tests currently do this), this only covers the case where one field is static and the other one is non-static, right? Adjusting your example so that either both fields are static or both are non-static seems to still fail in 5.10.1.

Yes, that's correct. A field supersedes a package private field with the same name in a superclass when the superclass resides in a different package unless a filter (Predicate) is applied that ignores one of the fields (such as a static check or a check for the presence of a specific annotation).

That's the status quo, albeit perhaps not very intuitive.

This also applies to lifecycle and test methods (and well, for any methods looked up via JUnit 5's reflection support).

We've had numerous discussions about this behavior over the years, and I think it might be worth discussing again within the team.

In light of that, I plan to create a new issue to revisit the topic.

Thanks for bringing it up! 👍

---

Related Issues

(so that I don't lose track of them)

• Detect annotations on overridden super type methods #960
• JUnit 5 computes overrides relationships incorrectly #2390
• Document best practices for test method and test class visibility #2626
• Revert disallowing private lifecycle methods #3242
• @BeforeAll method in super class skipped when it has same name as a @BeforeEach method in subclass #3498

[sbrannen]

Closely related to:

• Align method and field search algorithms with Java semantics #3553