Is it possible to get rid of from import statements in JUnit tests written in Groovy? I know you could do it in groovy scripts in GroovyShell by changing compiler configuration or import customizer.
I like to do same thing but:
IntelliJ should still provide code highlight and auto complete (I think I could do this
with gdsl file feature of IntelliJ)
I could still use IntelliJ's JUnit window to see which tests failed and which are passed.
Related
I am writing a set of groovy scripts to be used as part of a Jenkins Pipeline Library. Currently I am using plain old JUnit to test them but would like to switch to Spock. I simply run the tests from the command line by invoking the following groovy script.
import groovy.util.AllTestSuite
import junit.textui.TestRunner
System.setProperty(AllTestSuite.SYSPROP_TEST_DIR, "./tests")
System.setProperty(AllTestSuite.SYSPROP_TEST_PATTERN, "**/*Test.groovy")
TestRunner.run(AllTestSuite.suite())
I am trying to figure what the equivalent script would be to run Spock specifications. My first attempt was to switch the SYSPROP_TEST_PATTERN to "**/*Spec.groovy. I have one ...Spec.groovy file written and sitting under ./tests that looks like this:
#Grab(group='org.spockframework', module='spock-core', version='1.0-groovy-2.3')
import spock.lang.*
class UtilsSpec extends Specification {
def "Just testing"() {
expect:
1 + 1 == 2
}
}
When I invoke my groovy script though I get:
java.lang.RuntimeException: Don't know how to treat
/SourcCode/jenkins/pipeline-utils/tests/JustTestingSpec.groovy as a
JUnit test
That makes sense. I need to be using Sputnik but I've looked at the Spock and Sputnik source, and the Spock example project but these all assume you are using maven or gradle. I can't figured out the right way to invoke Sputnik directly. Any ideas?
Even though what you ask is possible and BalRog has already suggested a solution, in the long run it is better if you just use Gradle or Maven to run your tests from command line.
All Jenkins tutorials you will encounter will talk about Maven and/or Gradle and thus it would make much more sense to use a build system than custom scripts.
I'm trying to run the simple #Builder example shown on the Groovy 2.3 release page, using IntelliJ Idea 13.1.1.
Having created a vanilla groovy project and pasted the code, I get the following warnings where #Builder is declared on the Person class:
Missed attributes: forClass, prefix, builderClassName, buildMethodName, builderMethodName
(Essentially all the properties which don't have default values.)
The IDE is then also not seeing the builder() method which by default should have been added to the Person class, suggesting the AST hadn't been applied.
When the script is actually executed, it behaves as expected. So why do I see those errors in the IDE?
Update:
If I try to build from Gradle I get the following error during groovy compilation:
Can't load builderStrategy 'groovy.transform.builder.DefaultStrategy' java.lang.ClassCastException: groovy.transform.builder.DefaultStrategy cannot be cast to org.codehaus.groovy.transform.BuilderASTTransformation$BuilderStrategy
# line 3, column 1.
#Builder
If I try to switch to SimpleStrategy instead of the DefaultStrategy I get:
The builderStrategy class 'groovy.transform.builder.SimpleStrategy' on #Builder is not a builderStrategy
# line 4, column 1.
#Builder(builderStrategy = SimpleStrategy)
IntelliJ doesn't build/consider the Groovy AST. (This would be brittle and slow.) So until someone adds support for #Builder to IntelliJ, it won't understand it. I recommend to file a feature request.
The problem with #Builder and Gradle has been identified as a bug in the #Builder implementation. See my answer on the Gradle Forums.
Update: The Groovy bug filing was resolved with Groovy version 2.3.2.
I am trying to use a different location for external jar in soapUI. I updated the soapUI batch file by adding the below line.
set JAVA_OPTS=%JAVA_OPTS% -Dsoapui.ext.libraries="C:\Program Files\Groovy\Groovy-2.1.6\lib"
Now when i open soapUI and try to create an activexobject using scriptom(see below)
import org.codehaus.groovy.scriptom.*
def tdc = new ActiveXObject ('TDApiOle80.TDConnection')
I get the following error, the error seems weird because i know i am using groovy 2.1.6 as you can see from the path.
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: Could not instantiate global transform class org.spockframework.compiler.SpockTransform specified at jar:file:/C:/Program%20Files/Groovy/Groovy-2.1.6/lib/spock-core-0.7-groovy-2.0-20120930.020057-22.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation because of exception org.spockframework.util.IncompatibleGroovyVersionException: The Spock compiler plugin cannot execute because Spock 0.7.0-groovy-2.0 is not compatible with Groovy 1.8.0. For more information, see http://versioninfo.spockframework.org Spock location: file:/C:/Program%20Files/Groovy/Groovy-2.1.6/lib/spock-core-0.7-groovy-2.0-20120930.020057-22.jar Groovy location: file:/C:/Program%20Files/SmartBear/soapUI-Pro-4.5.2/lib/groovy-all-1.8.0.jar 1 error
Does anyone know why i am getting this error and what i can do to fix it?
I believe SoapUI (at least 4.5.1) is bundled with Groovy 1.8.0
At least is was back in May this year (2013)
You could try the suggestion posted on the page to upgrade, or I guess you're stuck with 1.8.0 functionality (and the non-2.0 spock dependency)
I have IntelliJ 12 and some groovy code (along with a pile of java code) in a project.
In intelliJ, i can see class A's import of some groovy code, and i have also included the library that has that code.
However, while the package itself is in one colour (for the import), the actual class being imported is in red, which implies an issue of some sort. Hovering the mouse over it reveals no issue though.
When i run a "make" or a "rebuild project" is where the problems start - i get
Groovyc: unable to resolve class com.blah.blah.blah.A
How can i resolve this?
Currently, my project setup is like so:
Under "Libraries" in (Project Structure -> Project Settings -> Libraries) I have:
the jar file with all the groovy code
the src jar file with all the groovy code
In the "Modules" section i have the - well, i don't know what to call it, the column isn't labelled - the library name from the libraries section associated with the src and class files, and the little "export" button beside it is ticked.
Incidentally, opening the class in intelliJ never shows the source code, which given the source is included struck me as weird.
Is there anything else I should need to do?
I've worked this one out, but if anybody knows why groovy cannot be in the "Resource Patterns" list and wants an upvote, do chime in
Oh, right.
I removed the !?*.groovy entry from the list of, um, entries in the File : Settings -> Compiler -> Resource Patterns thingy.
It doesn't seem to matter if "use external build" is on or off for this, but the !?*.groovy; entry cannot be there.
I wonder if anybody knows why?
I had the same problem and had to Add Framework Support and add Groovy to the project to get round this problem.
I created the project using gradle.
I just got your question in my Google results as I had a similar issue. My problem was that I was able to get the groovy code in my IntelliJ 12 project to compile ok, but it wasn't getting wired in properly when I tried to run unit tests within the IDE.
After some investigation, I uncovered that groovy and logback libraries were all set up in the project to be available in the runtime stage of the Maven build of the project, but that resulted in them not being available in the test stage. To fix this, I ended up manually updating the groovy-all and the logback libraries scope from runtime to provided under File->Project Structure->Modules->Dependencies. This allowed me to both compile and test within the IDE while including the Groovy modules as well as the Java modules.
Perhaps you had something similar going on in your project?
Six years later, I also just got this question near the top of my search results.
In my project my Unable to load class 'groovy.text.SimpleTemplateEngine' problem was actually due to a codenarc issue. I was able to resolve the issue by adding the following to build.gradle:
// codenarc version issue work-around
configurations.codenarc {
resolutionStrategy.eachDependency { DependencyResolveDetails d ->
if (d.requested.group == 'org.codehaus.groovy') {
d.useVersion '2.4.7'
}
}
}
I have
#RunWith(Suite.class)
#Suite.SuiteClasses( [
First.class,Second.class
])
public class MySuite{
}
But eclipse doesn't give me a "Run As Junit4 Test". All the individual test classes work fine with GUnit, the groovy unit test runner built into eclipse.
Any thoughts?
The only way I found to do this was to create a java class with a #Suite.SuiteClasses annotation as usual. You can put in the .class names of the Groovy classes you have for tests and it works well.
Kind of lame if you don't already have some java code to do it this way but I had a mix of Java and Groovy so it wasn't as big a deal.
The other option is to not use Suites at all and to use name patterns to find and run tests. Both ant and maven support this sort of pattern matching. I find it much easier than making sure I keep the suites up to date and Eclipse can just run all tests in a package if I want to do that.
Thanks for the help.
#Suite.SuiteClasses accepts Class[] as its parameter.
You may try:
#RunWith(Suite.class)
#Suite.SuiteClasses([First.class, Second.class] as Class[])
public class MySuite {
}