I have the following snipet of Groovy code
class Test
{
// #groovy.transform.CompileStatic
static main(args)
{
long start = System.currentTimeMillis()
def x = "3967"
println x ==~ /[0-9]+([1379])$/
println System.currentTimeMillis()-start
}
}
Which is supposed to test weather x is a number ending in 1,3,7,or 9
I'm using the groovy plugin for eclipse, so when i want to run the code I have a few options, I can either run it as a Groovy Script, or as a Java application. Here are the runtimes.
Groovy Script: 93ms
Java Application: 125ms
But then when I enable Static compilation, this happens
Groovy Script: 0ms
Java Application: 312ms
I'm confused,
1. I thought compiling to a Java application was supposed to be faster than running Groovy as a script.
2. Why is it that the Groovy script option gets so much faster with static compilation, and the Java one gets longer?
Related
When running Spock tests in Gradle (5.6.3) I see that the output can look something like this:
> :functionalTest > Executing test com.examp...baar.baaaaz.MyCustomGradleTasksP
In reality it should be like this if it showed the full path to the test running:
> :functionalTest > Executing test com.example.fooo.baar.baaaaz.MyCustomGradleTasksPluginFunctionalTest
Maybe it would also tell me which of the actual functional tests from that class it is running?
Is there a way to tell Gradle not to do this truncation so I can see all information?
It seems to be an internal implementation detail of Gradle itself:
private String createProgressLoggerDescription(TestDescriptorInternal testDescriptor) {
DecoratingTestDescriptor decoratingTestDescriptor = (DecoratingTestDescriptor)testDescriptor;
DefaultTestClassDescriptor defaultTestClassDescriptor = (DefaultTestClassDescriptor)decoratingTestDescriptor.getDescriptor();
return "Executing test " + JavaClassNameFormatter.abbreviateJavaPackage(defaultTestClassDescriptor.getClassName(), MAX_TEST_NAME_LENGTH);
}
https://github.com/gradle/gradle/blob/master/subprojects/testing-base/src/main/java/org/gradle/api/internal/tasks/testing/logging/TestWorkerProgressListener.java#L103
It may be possible to override this by implementing your own logger for Gradle as described here: https://docs.gradle.org/current/userguide/logging.html#sec:changing_what_gradle_logs
I'm trying to verify the calling of a method on a FileChooser.
I'm coding in Groovy, and this appears to be the problem.
I'm using the "incubating" Mockito feature which enables you to mock even a final class.
Code is:
FileChooser mockFC = mock(FileChooser.class)
doReturn(mockFC).when(spyCH).getFileChooser()
...
verify( mockFC, times( 1 )).showOpenDialog( any() )
This gives:
org.mockito.exceptions.misusing.UnfinishedStubbingException:
Unfinished stubbing detected here:
...
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:55)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:197)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:217)
at core.ConsoleHandlerFTs.shouldShowFileChooserDialogOnEnteringO(ConsoleHandlerFTs.groovy:91)
(NB line 91 is the verify line)
... and then goes on to talk about final method (showOpenDialog is not final), missing whenReturn (not applicable), etc.
The Mockito in my build.gradle in GRADLE_HOME is version 2.7.22.
FileChooser is javafx.stage.FileChooser.
Java version is 1.8.0_121.
I created an entirely new Gradle project... and did the same thing, with just Java files. Mocking worked OK, test passed!
By "adding back" the bits and pieces which make Groovy function in a Gradle project I seemed to get to the problem: after
apply plugin: 'groovy'
and (in dependencies)
compile 'org.codehaus.groovy:groovy:3.0.0-alpha-1'
the problem reoccurred. That is, even without having created any .groovy files. I then tried earlier versions of groovy, down to 2.3.11. Same result.
From searching I thought the "bytebuddy" package might be implicated but adding the following line to dependencies ensured that no earlier versions were present in GRADLE_HOME:
compile 'net.bytebuddy:byte-buddy:1.6.11'
Still getting UnfinishedStubbingException come up when I run the Groovy test file.
"Workaround" ... for anyone who's typically moving from Java to Groovy.
To learn Groovy I'm actually following a book, Groovy in Action, 2nd Ed, co-authored among others by JON SKEET!
I have now got to the part about testing, which is sort of designed into the language, as well as taking advantage of some of Groovy's amazing power.
It appears that Groovy's Spock testing framework is the way to go... and mocking final classes turns out to be possible with GroovyMock. I was able to write a test to do the job:
class XXX extends Specification {
#Rule
public TextFromStandardInputStream systemInMock = emptyStandardInputStream()
def xxx(){
given:
FileChooser fc = GroovyMock( FileChooser )
ConsoleHandler ch = Spy( ConsoleHandler ){
getFileChooser() >> fc
}
ch.setMaxLoopCount 10
systemInMock.provideLines( "o" )
when:
com.sun.javafx.application.PlatformImpl.startup( {} )
ch.loop()
Thread.sleep( 2000L ) // needs improvement with a Latch or something!
then:
1 * fc.showOpenDialog( _ )
}
}
... it'd still be nice if some Groovy übermind (Jon, are you there?) could find out why Mockito produces this UnfinishedStubbingException in Groovy.
NB you don't seem to be able to use GroovyMock in isolation within a Mockito test... it appears to be part of the Spock framework.
here is what i am trying to accomplish:
Build an uberJar for the EndToEndFunctionalTests tests :
task uberJar(type: Jar,dependsOn:[':compileGroovy']) {
zip64 true
from files(sourceSets.main.output.classesDir)
from configurations.runtime.asFileTree.files.collect {zipTree(it) }
with jar
}
as a result, i get:
EndToEndFunctionalTests-develop.local.SNAPSHOT.jar
so what i am trying to do is to execute this as:
$ java -jar EndToEndFunctionalTests-develop.local.SNAPSHOT.jar
no main manifest attribute, in EndToEndFunctionalTests-develop.local.SNAPSHOT.jar
is there a way to fake a main() and include it in the MANIFEST, so this jar executes.
I was able to run cucumber tests from the command line via gradle using cucumber runner, but what i want is to be able to run the jar because:
I would be able to run this jar anywhere, since it has all the dependencies
I would cut short the running time for these tests, in staging and qa, as i would have to just make it once, and run it in various environment, in the Continuous Integration Pipeline
src/main/groovy/Test.groovy
class Test{
public static void main(String[] args){
println 'dummy main'
}
and result:
java -jar Serenity-develop.local.SNAPSHOT.jar
dummy main
its is executable, but now i have to figure out if i can call cucumber runner from this class
I want to run the SOAPUI project xmls using Gradle script. The GRADLE script should read the project xmls from soapuiInputs.properties file and run automatically all. Please guide me step by step how to create Gradle script to run the SOAPUI projects in Linux server.
Note: We use SOAPUI version 5.1.2.
Probably the simple way is to call the SOAPUI testrunner directly from gradle as Exec task, like you can do from cli.
In gradle you can define the follow tasks (Note that I try it on windows but to do the same on linux as you ask simply you've to change the paths):
// define exec path
class SoapUITask extends Exec {
String soapUIExecutable = 'C:/some_path/SoapUI-5.2.1/bin/testrunner.bat'
String soapUIArgs = ''
public SoapUITask(){
super()
this.setExecutable(soapUIExecutable)
}
public void setSoapUIArgs(String soapUIArgs) {
this.args = "$soapUIArgs".trim().split(" ") as List
}
}
// execute SOAPUI
task executeSOAPUI(type: SoapUITask){
// simply pass the project path as argument,
// note that the extra " are needed
soapUIArgs = '"C:/location/of/project.xml"'
}
To run this task use gradle executeSOAPUI.
This task simply runs a SOAPUI project, however testrunner supports more parameters which you can pass to soapUIArgs string in executeSOAPUI task, take a look here.
Instead of this if you want to deal with more complex testing there is a gradle plugin to launch SOAPUI project, take a look on it here
Hope this helps,
I'm working on a Java project that uses Gradle as its build system.
I want to add some bdd tests using Cucumber-JVM. Following this example I was able to configure Gradle's build.gradle to have a task called cucumber, and I was able to execute that task using "gradle cucumber".
But what I am looking for is a way to have Gradle run that task automatically during its test phase (where it runs all the other regular unit tests). I also want the build to be flagged as failed if any of the cucumber tests fail (strict=true).
Is this possible? I don't know a lot about Gradle and Google so far has produced nothing really useful.
Okay so I figured out how to achieve this. Simply add this to build.gradle:
test << {
javaexec {
main = "cucumber.api.cli.Main"
classpath = configurations.cucumberRuntime + sourceSets.main.output + sourceSets.test.output
args = ['--strict', '--monochrome', '--plugin', 'pretty', '--glue', 'com.mypackage', 'src/test/resources']
}
}
All you really need are the feature file and the steps java files that implement the glue code. You do not need the xxxCukesTest.java file with a #RunWith annotation since Gradle ignores it. You may want to keep it anyway because it enables you to run tests from your IDE.
Works really neat!