The problem only occurs when I am trying to debug a test via the IntelliJ debugger. It does not happen when I just simply run the test.
CustomerChoiceRepository is a normal Spring Boot JPA repository which here is being mocked with #Mock.
When this line executes in the debugger I get the following error in the watch section of the variables:
The entire error message is:
Method threw 'org.mockito.exceptions.misusing.UnfinishedStubbingException' exception. Cannot evaluate com.item.repository.jpa.CustomerChoiceRepository$MockitoMock$1318657964.toString()
Again this is only is detected in the IntelliJ debugger, as a result the test fails only when I am debugging it.
So my question is: what is happening here?
Is this a bug ? Is this something that I fail to understand because I do not know the internals of Mockito particularly well ?
Your IntelliJ is calling toString on the mock during stubbing, which causes the exception.
Check your debugger settings
By default, IntelliJ calls toString on objects in debugger window, but only on objects that override that method. This behaviour is customizable, currently in Preferences -> Build Tools -> Debugger -> Data Views -> Java -> Enable 'toString' object view, but the settings mey differ between IDE versions.
See:
Is it possible to tell IntelliJ IDEA to automatically invoke toString() on the objects inspected in watches, variables, tool tip windows?
Don't call methods on mocked object during stubbing
See:
How do Mockito matchers work?
How does mockito when() invocation work?
Related
I am able to debug my application by remote debug in intellij. But how to debug the method like
list in below example.
Student.createCriteria().list {
'in'('Id', params.id)
}
I want to debug the list method to get the query which is getting fired but debug point don't go there.
You can debug GORM code pretty much like you debug all JVM classes. You can step-into the GORM code. If you don't want to step into the GORM code but instead want to put the breakpoint in the GORM code directly, it is impossible to say for sure where you should put a breakpoint because I don't know which GORM implementation you are using and which version of that implementation. If you are using GORM for Hibernate version 7.0.3.RELEASE, then you may want to put a breakpoint at https://github.com/grails/gorm-hibernate5/blob/df05ec7e99a6b12718dfc814a7cbe4073b09a881/grails-datastore-gorm-hibernate5/src/main/groovy/org/grails/orm/hibernate/query/AbstractHibernateCriteriaBuilder.java#L1570.
I hope that helps.
I'm running out of ideas...
My spring boot app behaves fine when I run it in indellij and gradle idea plugin is applied (apply plugin: 'idea').
Once I remove the plugin from build.gradle it behaves similarly to app executed with java -jar app.jar - there is subtle but important difference, description below.
I have the following scenario, current tx fails due to some exception, tx is marked as roll-back-only, exception is caught and its handling consists of registering post tx recovery activity with TransactionSynchronizationManager.registerSynchronization (new tx).
The code works fine in intellij with idea plugin, when I remove plugin declaration or run spring boot jar with java -jar registering process (post tx failure task) fails with exception:
Caused by: java.lang.IllegalStateException: Transaction synchronization is not active
at org.springframework.transaction.support.TransactionSynchronizationManager.registerSynchronization(TransactionSynchronizationManager.java:291) ~[spring-tx-4.3.10.RELEASE.jar!/:4.3.10.RELEASE]
Btw, the code is in kotlin if it matters.
Any ideas?
UPDATE
I think there is some kind of race condition because in debug mode, even w/o idea plugin, the app behaves as expected (registering process is successful).
I solved my problem and the root cause was quite surprising...
Apparently there's a problem with correct processing of custom Spring annotation.
The method which was supposed to open a new transaction was not annotated with a standard #Transactional annotation, but with custom, application specific annotation (#Transactional with custom tx settings). Debugging session revealed that new tx was not being open. That's it! Inlining custom annotation nearly solved a problem.
Another flaw I detected was a function which was not open, quite strange because the function was not transaction entry point (som further call).
Kotlin compiler bug?
Anyway, lessons learned - pay attention to custom annotations behaviour; refresh knowledge about rules for final/open.
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.
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).