I have a Spock unit test in a Grails app. In IntelliJ IDEa I can either run it with grails environment and then it means I wait a minute until the environment loads to run the test even though I do not need the environment.
The other option is to run it with JUnit. This works nicely in a Grails app without my own plugins. However, when I run it in a Grails app that has a plugin of another Grails app I have, it crashes on NoClassFound. It does not see the classes from the plugin that I included.
When I checked in IDEa the project structure, indeed the sources nowhere include a folder where the plugin classes would be included. For some reason the plugins in plugins section in BuildConfig.groovy do not appear in the classpath anywhere, they are not found in the external libraries section or anywhere else.
Is there a way to tell grails not to spin up its environment when running some of my tests? Or how can I include my plugin in the classpath for Groovyc to see it when building for testing?
The problem occurs also when simply pressing Build Project in IntelliJ IDEa. The project we are working with is simply run with grails and is never built (beyond how grails builds it). When you try to build it in IDEa, it fails on NoClassDefFound of plugin class.
Versions:
IntelliJ IDEa 2021.2
Grails 2.5.6
EDIT: Ok, it seems like grails apps are to be tested via their command-linke with grails test-app. When Grails runs in interactive mode, test-app won't have to reinitialize the environment, cause it's already running, so it runs faster.
However, as I found here Slow Grails test starting in Intellij IDEA it seems like there's no way to run grails in interactive mode from within IDEa in a way that would enable IDEa test runs to use such interactive console. Which means I'm forced to run tests via command-line. Not happy.
Edit 2: At some point in time I have managed to get the compiled tested.class to the out folder. This enabled running the test instantly via IDEa circumventing the Grails glory. However, I have no idea how I got it to out folder and after removing it I am unable to compile it again and get it there.
Related
I'm trying to upgrade a Grails app from 3.3 to 4 (specifically 4.0.3 for now) and the Views-Json 2.0.2 plugin. Profile is angular.
When I run the app in development mode everything works. However when I attempt to build using gradlew :server-api:assemble the build fails at the Task :server-api:compileGsonViews (yeah, renamed 'server' to 'server-api' for clarity).
It looks like it's not finding my Java classes (there are a few under src/main/java).
I've see refs to setting the classpath for the compileGsonViews, but I was undable to make it work.
Anyone with suggestions?
Running on Windows 10 with latest OpenJDK 1.8.x
Somehow I seem to have stumbled on the solution. In my build.gradle I had enabled the grails pathingJar, commenting that out allowed my war to build. However with the property commented out, I was unable to use the gradlew bootRun command as it failed due to the path being too long.
The solution (for me) was to add a build property, the build file then looks like:
def usePathing = Boolean.valueOf( System.getProperty('pathingJar', 'false') )
if (usePathing) {
grails {
pathingJar = true
}
}
If I was better with gradle I think I could (maybe) determine the goal that is being targeted and use that, but the above works. The commend to assemble the war is the same; but to run the app directly I need to make it gradlew server-api:bootRun -DpathingJar=true
My application uses the following versions:
Geb: 0.9.2
Selenium: 2.26.0
Grails: 2.1
Spock: 0.7
And I'm running on a linux box with the following:
Firefox: 14
Centos: 5.3
I have a grails application and I am using Geb in the functional test phase.
If I'm starting from a clean environment (.grails has been wiped) and I run my tests they all go through fine, geb runs up firefox, does the tests and gives me the report.
However subsequent runs of the functional tests all tests will fail with:
geb.giver.DriverCreationException
which is apparently caused by:
java.lang.NoSuchMethodException
Now if I trash my .grails and run again, the next time the pass fine. Just want to be able to run the tests consistently.
Any help would be greatly appreciated!
Cheers
UPDATE:
Below is the gist of the stack trace (copied by hand so apologies for any typos):
geb.driver.DriverCreationException: failed to create driver from callback 'GebConfig$_run_closure#6f61a3c4'
at geb.driver.CallbackDriverFactory.getDriver(CallbackDriverFactory.groovy:35)
at geb.driver.CalbackDriverFactory.getDriver_closure3(CachingDriverFActory.groovy:80)
...
Caused by: java.lang.NoSuchMethodError: org.apache.http.conn.scheme.Scheme.<init>(Ljava/lang/string;ILorg/apache/http/conn/scheme/SchemeSocketFactory;)V
at org.openqa.selenium.remote.internal.HttpClientFactory.getClientConnectionManager(HttpClientFactory.java:59)
at org.openqa.selenium.remote.internal.HttpClientFactory.<init>(HttpClientFactory.java:48)
at org.openqa.selenium.remote.HttpCommandExecuter.<init>(HttpCommandExecuter.java:118)
...
I had this exact issue in the past. Exactly with HttpDriver classes in the stacktrace and happening on the second run after a clean. It's due to some of your Grails plugins pulling in a conflicting version of HttpClient.
I found that it's usually a plugin that transitively pulls in the release plugin but doesn't exclude it from exporting. The way to find the culprit is to go through all of your installed plugins for that app in your .grails directory and looking at their dependencies to find the one that is pulling the release plugin in and then either remove it or update it to a newer version as more and more plugin authors are excluding release plugin from exporting and I also believe that latest versions of release plugin don't depend on HttpBuilder anymore.
Lately I've been trying to run my spock tests in IntelliJ (which used to work beautifully and had great debugging / specific test re-running on failure features) and in the past few months I've began getting the following error:
| Error Error executing script TestApp:
(class: com/company/MyServiceSpec, method: super$2$oldImpl signature:
(Ljava/lang/Object;)Ljava/lang/Object;)
Illegal use of nonvirtual function call (Use --stacktrace to see the full trace)
It's a spock test that runs just fine from the command line, individually (by specifying the class) or in the entire test-app series. Virtually all of the spock and plain old Unit or Integration tests I have on this project give similar failures in IntelliJ.
I've tried twiddling with the run features of the test (having classpath on or off, running an individual method, a whole test class, or the entire test series) with no luck to remedying the situation. I've also done a grails clean and tried re-running them from IntelliJ : that looked as if it worked once and I was able to run the tests for a little while, but then quickly after doing some work the problem now persists.
I know this is a bit of a vague question, but has anyone seen similar failures and found a reliable remedy? I'm on Grails 2.1 and Spock 0.7, same problem in both IntelliJ 12 and 13
I managed to solve this problem adding the following env variable in my configuration:
_JAVA_OPTIONS='-Xverify:none'
First check your configurations and clear out the test that you have ran that are now failing. It is possible you ran the tests as JUnit and now when you are running them again them they are defaulting this behavior.
Note: You can determine if this the issue by running your tests via the command line (e.g. grails test-app unit com.yourPackage.Whatever) if they pass as expected then follow the steps below to clear your saved test configurations in IntelliJ
IntelliJ Steps
Click Run
Click Edit Configurations
In the left pane of the pop up click the arrow to unroll the jUnit tests
Next Click on a test and then click the minus icon ( do this for each to clear them all )
Go to your test you want to run and right click it and make sure you select the grails choice and not jUnit.
I have a set of tests for spring-security 3.1.3 with embedded ldap server that runs properly from eclipse or when run through gradle with -Dtest.single option. However when i do a clean build to run the entire set of tests in the project the execution hangs at the point where it hits those tests, at which point i have to kill the gradle process. If I #Ignore the ldap tests other tests work fine. These tests work properly if i dont use embedded server i.e connect to an external server. Probably something to do with fact that gradle executes tests in multi-threaded way and it tries to host an in-memory server and all that.
Any body faced similar issues ? and how might i get more useful info on what might be going on ? --info or --debug on gradle doesn't help and the test reports (like the ones generated in case of a normal test failure ) are also not generated in case of killing the gradle process .
You probably need to set maxParallelForks to 1.
Why don't you copy the approach used by Spring Security itself, which configures a separate task for integration tests? It sets maxParallelForks to 1 for those tests.
That way you can continue to benefit from running unit tests in parallel.
I'm using STS latest version (2.7) and latest grails as well. After I created a freshly grails project in STS it freezes in the updating grails dependencies for a long time and it comes out as a timeout error. And it follows by some GroovyObject error, but the project still runs fine in command-line. So I ditched STS for refreshing dependencies, and I included the dependency in BuildConfig.groovy and use grails compile but I still got ClassNotFound error when compiling, it's like grails didn't pick up the Ivy CLASSPATH. So, I'm thinking of changing it to Maven to resolve any dependencies.
My question would be which one is better and integrated seamlessly in STS or Eclipse?, but I still want to use grails commands, not maven.
If your project is just a grails project - use grails dependencies.
I've experience with mavenized grails project, and plain grails project. First is good when you have multimodule project, and only one of them is grails module. At this case you'll lost all grails commands, you need to use commands like mvn grails:run-app and it's complicated thing to pass arguments into commands :(