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

Version 1.1.0 of guice-extension breaks parameterized tests. #4

Closed
SergeyAlekseevN opened this issue Feb 21, 2019 · 1 comment · Fixed by #5
Closed

Version 1.1.0 of guice-extension breaks parameterized tests. #4

SergeyAlekseevN opened this issue Feb 21, 2019 · 1 comment · Fixed by #5

Comments

@SergeyAlekseevN
Copy link
Contributor

After updating Guice-Extension to the new version, the parameterized tests broke down.

@ExtendWith(GuiceExtension.class)
public class Test {
    @ParameterizedTest
    @ValueSource(strings = {"one", "two", "three"})
    void test(String count) {
        assertTrue(true);
    }
}

Error:

org.junit.jupiter.api.extension.ParameterResolutionException: Discovered multiple competing ParameterResolvers for parameter [java.lang.String arg0] in method [void com.tests.Test.test(java.lang.String)]: name.falgout.jeffrey.testing.junit.guice.GuiceExtension@19e4653c, org.junit.jupiter.params.ParameterizedTestParameterResolver@795509d9

I researched this problem and found that the reason is built-in binding for String.class.
String has empty constructor and binds in runtime by Guice to "" (empty string).

See line 206:
adf2f4e#diff-5eef6748419687f2efdf650d6649f118

I suggest to add additional annotation with bindingModeParam(ALL,EXPLICIT_ONLY) to set binding mode and process it in supportsParameter method.

..or just make workaround with built-in binding String.class.

I would like to hear your opinion and suggestions on this issue.

@JeffFaer
Copy link
Owner

Nice find. Explicit only is probably a non-starter, because a lot of people rely on implicit just-in-time bindings for their @Inject annotated classes.

Special casing String to be explicit only makes sense, though. If you want to take a crack at it, I'd be happy to take a PR. Otherwise I'll probably get around to this in the next couple of weeks

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

Successfully merging a pull request may close this issue.

2 participants