I am attempting to upgrade our application to Java 8 and am having some issues with maven and surefire. When I run all of my unit tests, a handful of them fail when using EasyMock.createMock with the following error: java.lang.NoClassDefFoundError: Could not initialize class com.sun.proxy.$Proxy33. Not all instances of EasyMock.createMock fail, and I can't find anything special about the classes we're mocking where it fails. Also, if I run the unit test inside of IntelliJ it works perfectly fine. It's only when running it via maven directly that it fails. I haven't been able to find anything that is causing this, but I'm assuming it has to be some sort of classpath issue. Any help would be greatly appreciated.
That is a strange error. The Proxy33 means you are mocking an interface. And that something failed at class loading.
Check if you have static initializers in your code. You can also add remote debug to maven and break on the exception.
Related
Recently, while running some tests, I wanted to use TestNG instead of JUnit.
however when I added the dependency to pom file, imported the jar files.
imported annotation, when I ran it, it passes for JUnit, but it's failing for TestNG with NPE (NullPointerException)
java.lang.NullPointerException: Cannot invoke "org.springframework.context.ApplicationContext.getBean(java.lang.Class)" because "this.context" is null
can someone show me the way to fix this issue?
Thank you very much in advance!
Make sure you have done the correct injection. Refer to the below answer -
https://stackoverflow.com/a/2608580/14899650
I am building a maven project with Kotlin and Quarkus. I splitted unit and integration tests so I have a structure like :
src/
integration-test/ -> where I annotate classes with #QuarkusIntegrationTest
main/
test/ -> where I annotate classes with #QuarkusTest
I have an issue when trying to run all tests in integration-test (with mvn failsafe command, or with intelliJ). All the tests inside the first test class pass, but then the application fails to start before running tests of the second test class, stating that application port is already in use:
io.quarkus.runtime.QuarkusBindException: Port(s) already bound: 8081: Address already in use
When running each test class separately, all tests pass.
I have tried setting test-port: 0 in my application.yml, but I get the same error with the random port. Is there a way to tell quarkus to keep the same app instance for all integration test class ? Or to check that the first one has teminated completely before running the next class ? I don't know what I am doing wrong with this #QuarkusIntegrationTest annotation.
Thanks in advance for the help.
Well, this was a dumb issue; One of my test was annotated #QuarkusTest instead of #QuarkusIntegrationTest.
I have some tests that need to check if the main code did a System.exit(...). This works very nicely with suggestions from https://stackoverflow.com/a/309427/1023341. But when running these tests in Jenkins (in stead of in my IDE Eclipse) and later when trying them on the command-line using Maven-Surefire (as Jenkins does) the tests fail without telling me why. It only tells me: Error occurred in starting fork, check output in log.
When setting a SecurityManager during JUnit (5) using System.setSecurityManager and using Surefire plugin, you should restore the SecurityManager after the test.
SecurityManager origSecurityManager = System.getSecurityManager();
try {
// ... code under test here ...
} finally {
System.setSecurityManager(origSecurityManager);
}
or some other more suitable form. This makes sure that Maven-Surefire-plugin stays happy.
Edit for suggested pre-baked solutions:
There are two pre-baked libraries for this:
junit5-system-exit
system-lambda
As the name suggests: the system-lambda is a Java 8+ solution. Both are JUnit 5 compatible. My personal preference lies with the lambda solution.
More background information
I'm completing doing everything same as described in tutorial at Grail website . However I'm receiving this strange error message :
Method on class [com.secure.Role] was used outside of a Grails application
I've done it in my business computer and personal notebook. I've tried to it with Spring IDE and different grails versions. What's the problem can not understand.
If you are trying to run a unit test without first applying mocking to a domain class then you will get this error.
Also integration tests cannot curerntly be run in an IDE and require use of the command line (some IDEs integrate the command line to run these tests). If you run an integration test from the IDE you will likely get an error like this.
The integration test classes generated for me by Grails when I created my domain classes do not extend the class GroovyTestCase. However, I have seen it recommended by many authors (here is an example in order to use the shouldFail method, which indeed seems to work).
However, extending my test class from GroovyTestCase has resulted in the following error message when I run test-app in the interactive Grails console:
Spring Loaded: Cannot reload new version of foo.barTests
Reason: Supertype changed from java/lang/Object to groovy/util/GroovyTestCase
Is this something I should be concerned about? I have searched online and cannot find other people complaining about this error, so it might be something new with Grails 2.2. Please advise.
I am running my tests in the grails interactive console (what you get when you run grails without arguments). I've left my tests inheriting from Object for a while, but when I run test-app I still occasionally get those messages output to the HTML test report (of the "changed from GroovyTestCase to Object" variety).
I am quite sure it's a Grails bug related to
AST Transformation annotations
spring-loaded module
As I've encountered this strange behaviour as well.
The steps that caused this problem seem to be that a Groovy class is compiled once without transformation, so that it's a subclass of java.lang.Object.
When the AST transformaton kicks it, the class is recompiled again. This time, it becomes a subclass of another class. Then Spring-loaded fails to re-load them into the memory (as JVM does not allow the same class to redefine its super class).