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
Using JMockit in WildFly will give many false-positive "internal class mocked" warnings #339
Comments
Thanks. The current implementation fails to properly check for mockup and target classes that come from jar files. This should be easy to fix. |
You think so? Besides that the locations don't necessarily need to include the JAR name per-se, you then still cannot reliably do the validation you wanted. You can change it so that the false-positives are away, but you will probably also remove most of the real findings if you restrict the check on JAR, because target and mockup will not be in the same JAR. |
Your test is also highly test-runner specific anyway. One example, I use Gradle to run normal JUnit tests with JMockit. I have multiple projects and multiple sourcesets. In the example I tested now I have a test in the
So the check you do is very much dependent on the used toolchain. |
Here you have a minimal example Gradle project where you see this: test.zip |
May I ask whether this will get some fix for the version released soon? |
If you use JMockit within WildFly, the calculation whether a
MockUp
target class is internal or not is not working properly.Each
MockUp
you create that mocks a class that is one of your libs (not a JRE class or something that is shipped with the app-server, but shipped with your EAR) will produce the "internal class mocked" warning, even the three JMockit-internal startup mocks are affected.e. g. the JMockit-internal startup mocks for
org.junit.runner.notification.RunNotifier
,org.junit.runners.BlockJUnit4ClassRunner
andorg.junit.runners.model.FrameworkMethod
will produce the warning, because inmockit.MockUp.areClassesFromSameCodebase():260
the variable values arehaving a mock like the following
which is definitely not in our codebase also gives the warning, this time the fields are
As the own code can be defined in an arbitrary amount of own JARs, it is hard to say which classes are internal and which are external.
The text was updated successfully, but these errors were encountered: