Spring Aspects to provide basic static mock test functionality [SPR-6274]

[spring-projects-issues]

Ben Alex opened SPR-6274 and commented

Spring Roo presently supports creation of mocks for static methods. As per email discussion between Juergen, Ramnivas and Ben, it would be useful if these classes were ported to Spring Aspects.

Please see the following location in Spring Roo code for the templates to use:

https://fisheye.springsource.org/browse/spring-roo/trunk/addon-test/src/main/resources/org/springframework/roo/addon/test/AbstractMethodMockingControl.aj-template
https://fisheye.springsource.org/browse/spring-roo/trunk/addon-test/src/main/resources/org/springframework/roo/addon/test/JUnitStaticEntityMockingControl.aj-template
https://fisheye.springsource.org/browse/spring-roo/trunk/addon-test/src/main/resources/org/springframework/roo/addon/test/MockStaticEntityMethods.java-template

Please see the following Jira issues for background on this feature and key considerations:

https://jira.springsource.org/browse/ROO-92
https://jira.springsource.org/browse/ROO-202
https://jira.springsource.org/browse/ROO-272

Once this functionality has been added to Spring Framework, I will modify the Roo usage accordingly (as is being tracked in ROO-314).

---

Issue Links:

• ROO-314 Use Spring Framework-provided static mock integration test services ("is depended on by")

[spring-projects-issues]

Ben Alex commented

I just tested (via mvn test) a Roo-built app against Spring Framework 3.0.0.BUILD-20091028.205923-196 (using roo script vote.roo). It gives the following error:

[ERROR] can't determine annotations of missing type org.junit.Test
when weaving type com.springsource.vote.domain.Vote_Roo_ToString
when weaving aspects
when weaving
when batch building BuildConfig[null] #Files=17 AopXmls=#0
[Xlint:cantFindType]
[WARNING] advice defined in org.springframework.mock.staticmock.JUnitStaticEntityMockingControl has not been applied [Xlint:adviceDidNotMatch]
[WARNING] advice defined in org.springframework.mock.staticmock.AbstractMethodMockingControl has not been applied [Xlint:adviceDidNotMatch]

The pom.xml for this project contains a declaration for JUnit, but with a <scope>test</scope>. If I change the scope to compile, the tests pass.

As such I am wondering whether the movement of the aspects to the Spring Aspects library might be responsible for this? Perhaps we might need a Spring Aspects library that has scope at testing time only?

[spring-projects-issues]

Ramnivas Laddad commented

Fixed by marking junit dependency as 'compile'. Since mocking aspects depend on junit at compile time, this is the right scope, anyway.

[spring-projects-issues]

Ben Alex commented

The trouble with making it "compile" scope is that JUnit will then appear in the resulting WAR's WEB-INF/lib directory. I just quickly looked over the code for this feature and JUnitStaticEntityMockingControl appears to be the only type that requires Junit at all anyway (specifically for the pointcut expression). In view of this it doesn't seem such a bad idea to just remove the @Test reference from the pointcut, as there is already the @MockStaticEntityMethods annotation required to match on the pointcut anyway.

[spring-projects-issues]

Ramnivas Laddad commented

Ben, one problem I see with removing @Test reference is that then the mocking logic will apply to even non-test methods in a class marked with @MockStaticEntityMethods (a class-level annotations). I wonder if marking the scope 'provided' will help here, since dependencies with the 'provided' scope aren't automatically inherited. User application will need to supply this dependency, but it will occur naturally due to the tests in it.

[spring-projects-issues]

Ben Alex commented

Do you mean using scope "provided" in the Spring Aspects POM for JUnit, and then having the end user project's POM include a JUnit dependency with a scope of "test"? If so, that will work fine when compiling the tests but I suspect will fail when compiling the normal classes earlier in the build. The failure will be because the "compile" phase references Spring Aspect and it in turn expects JUnit to be in the classpath, but the user project's scope would prohibit that from being included until the "test" phase. Perhaps I'm missing something?

Regarding just removing the @Test reference, one option might be to make @MockStaticEntityMethods a method-level annotation rather than a type-level annotation. Or introduce a special annotation that excludes a particular method from having mocking (@MockStaticEntityMethodsDisabled?).

We still have the other two options identified earlier, being to split this feature out from Spring Aspects into Spring Test Aspects, or just live with the junit.jar appearing in the resulting WAR files and direct people to this issue so they can see the background. My only reservation with the latter (aside from WAR payload, which I am always trying to minimise as a general principle) is that most people won't even do static mock testing yet this JUnit dependency will be required by every person who is using Spring Aspects.