@Transactional on test class ignored for test methods declared in superclass [SPR-7824]

[spring-projects-issues]

Andrei Badea opened SPR-7824 and commented

Have the following test classes:

@ContextConfiguration(...)
public class MyTestBase extends AbstractTestNGSpringContextTests {

	protected boolean beforeTransaction;

	@Test
	public void test() {
		Assert.assertTrue(beforeTransaction);
	}
}

@TestExecutionListeners({ TransactionalTestExecutionListener.class })
@Transactional
public class MyTest extends MyTestBase {

	@BeforeTransaction
	public void before() {
		beforeTransaction = true;
	}
}

Run MyTest.java. The expectation is that the @Transactional annotation is handled and the test() method runs in a transaction. This does not happen. AbstractFallbackTransactionAttributeSource seems to have been written with interfaces in mind, where the "most specific method" is in the implementation class. So for the case above, one would expect the most specific method to be MyTest.test(), but it actually is MyTestBase.test(). I did not find a way to get a java.lang.reflect.Method handle for MyTest.test().

---

Affects: 3.0.4

Issue Links:

• @Transactional annotation does not apply to inherited methods from abstract class during tests [SPR-11252] #15877 @Transactional annotation does not apply to inherited methods from abstract class during tests ("is duplicated by")

[spring-projects-issues]

Juergen Hoeller commented

Hmm, this could be deliberate, like as follows: If a base class isn't annotated with @Transactional, the methods declared there are never executed transactionally - not even if a subclass adds @Transactional, which will then only apply to methods declared in that specific subclass and further down the hierarchy.

What do you think, Sam? Has there ever been an actual decision here, or did the present semantics just happen?

Juergen

[spring-projects-issues]

Sam Brannen commented

It's partially happenstance but chiefly by design.

1. For consistency, the semantics for @Transactional in tests are deliberately identical to the semantics for @Transactional in application code. We therefore use the same look-up mechanism (i.e., AnnotationTransactionAttributeSource which extends AbstractFallbackTransactionAttributeSource).
   • As Andrei pointed out, AbstractFallbackTransactionAttributeSource's computeTransactionAttribute(Method, Class) method takes the target class as the second argument, but instead of searching in the target class for the presence of the annotation, it searches in the declaring class (see snippet below).
2. I thought the present semantics (which were in place for @Transactional prior to the TestContext framework) made sense and saw no reason to provide different semantics in tests.

// Second try is the transaction attribute on the target class.
txAtt = findTransactionAttribute(specificMethod.getDeclaringClass());

The comments in the above code snippet state explicitly that the intention is to search on the target class; however, specificMethod.getDeclaringClass() is not always the target class. Thus, if any change is made in conjunction with this JIRA issue, I think it should be limited to replacing specificMethod.getDeclaringClass() in the above code with targetClass. But, that would define new semantics for @Transactional in existing production code as well, and that's something we probably want to avoid.

So, in summary, I am inclined to resolve this issue as "Works as Designed".

Regards,

Sam

[spring-projects-issues]

Sam Brannen commented

Resolving as Works as Designed.

See discussion in the comments for details.