Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-spock tests failing with IllegalArgumentException #11

Closed
M21B8 opened this issue Aug 31, 2017 · 3 comments
Closed

Non-spock tests failing with IllegalArgumentException #11

M21B8 opened this issue Aug 31, 2017 · 3 comments

Comments

@M21B8
Copy link

M21B8 commented Aug 31, 2017

My project has a large mix of Spock and Junit tests, the spock tests use a mix of Mockito and Spock mocks, the JUnit tests just use Mockito, since adding this library all of my non spock tests fail with the following error:

Stacktrace
java.lang.IllegalArgumentException: MockAttachingTestExecutionListener can be applied only for spock specifications
	at com.pchudzik.springmock.spock.spring.MockAttachingTestExecutionListener.beforeTestMethod(MockAttachingTestExecutionListener.java:48)
	at org.springframework.test.context.TestContextManager.beforeTestMethod(TestContextManager.java:269)
	at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)

Is there anyway to globally turn the listener off, and only add it to the tests where I'm making use of the library? (until such time as I can actually convert the whole code base)

@pchudzik
Copy link
Owner

You can check if latest snapshot version will work for you (it probably will not, it might fix the error but you'll probably hit more complicated issues later).

I've refactored the check that was raising the exception. It doesn't make any sense and I didn't considered that someone might use spock and junit at the same time, although I did it myself :)

The problem might a bit more complicated that it looks. Right now mockito and spock infrastructure are completely different and separated things. Each one setups some stuff, and as a results one will overwrite beans registered by another. For example double factory might get overwritten and as a result you can end up with spock mocks in junit test case.

if that's the case then you'll need to do some coding to get this running
Annotate your test class with @BootstrapWith and provide TestContextBootstraper which will call org.springframework.test.context.support.AbstractTestContextBootstrapper#getContextCustomizerFactories and then remove all springmock customizers and then add one customizer for each testing framework. Something like this:

class JunitSpringMockContextCustomizer extends DefaultTestContextBootstrapper {
  @Override
  protected List<ContextCustomizerFactory> getContextCustomizerFactories() {
    return Stream.concat(
            super.getContextCustomizerFactories().stream().filter(this::isNotSpringMockCustomizer),
            Stream.of(new com.pchudzik.springmock.mockito.spring.MockitoContextCustomizerFactory())
        ).collect(toList());
    }
}

and very similar one for spock but use com.pchudzik.springmock.spock.spring.SpockContextCustomizerFactory instead of MockitoContextCustomizerFactory. You can try and figure out the single class which will do it more dynamically but I'm sure you get the idea.

Now about long term solution. How should it look? I see few options here but I'm not sure which one will the best.

  • leave it as is if it is be working. I don't expect it to work...
  • allow to manually select mocking library and disable/enable it for single test classes (sounds like a lot of effort for the user to select runner for each test class individually...) Something like the workaround I've proposed above, maybe looking a bit better on the outside but still pretty ugly...
  • automagically detect what is being executed and (spock specification/junit test case) and register infrastructure appropriately - might be tricky to maintain in longer perspective. Something like the workaround above but bundled in the library.
  • something else?

@M21B8
Copy link
Author

M21B8 commented Sep 1, 2017

The 1.1.0-SNAPSHOT actually works for us, all our tests pass once I use that version :) Any chance of it becoming a release version?

Thanks

@pchudzik
Copy link
Owner

pchudzik commented Sep 6, 2017

I've just released version 1.1.0 to maven central.
testCompile('com.pchudzik.springmock:springmock-mockito:1.1.0')

Since it's working for you then I'm closing this one. In case of any further issues do not hesitate to reopen.

@pchudzik pchudzik closed this as completed Sep 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants