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.
Related
I'm currently trying to integrate clojure into gradle springboot project, even though it works, I do have to use RT.loadClassForName("au.edu.uq.core"); before the Clojure.var could access the function, if I comment the RT.loadClassForName("au.edu.uq.core");, there will be an error like:
Exception in thread "main" java.lang.IllegalStateException: Attempting to call unbound fn: #'au.edu.uq.core/hello-from-clojure.
But in the build.gradle I already include classes.dependsOn compileClojure.
There are screenshots of build.gradle, Main Java Class and the clojure namespace. This is a tiny demo project for me to learn gradle, any suggestions to make this build process more elegant?
Starting script is ./gradlew bootRun and ./gradlew run
//This is the Java Main Class
//This is the clojure namespace
//This is the build.gradle
From what I got from the screenshot of the Main class, it seems you are using Clojure.lang.RT to load your function, while the official reference documentation suggests otherwise:
Functions in clojure.core are automatically loaded. Other namespaces
can be loaded via require:
IFn require = Clojure.var("clojure.core", "require");
require.invoke(Clojure.read("clojure.set"));
My suggestion would be to try something like:
IFn require = Clojure.var("clojure.core", "require");
require.invoke(Clojure.read("au.edu.uq.core"));
IFn helloFunction = Clojure.var("au.edu.uq.core", "hello-from-clojure");
helloFunction.invoke();
I try to run my BDD scripts via gradle getting the following error message after updating IntelliJ to 2016.2
No implementation for net.thucydides.core.webdriver.WebdriverManager was bound.
while locating net.thucydides.core.webdriver.WebdriverManager
The code raising the error is this:
#Before
public void jeffCanBrowseTheWeb() {
givenThat(jeff).can(BrowseTheWeb.with(theBrowser));
}
The binaries to the browser are linked like this:
test {
System.setProperty("webdriver.chrome.driver","D:\\lib\\chromedriver.exe")
/* Pass all system properties: */
systemProperties System.getProperties()}
The compile dependencies for selenium-java are pointing to the version '2.53.1'
The gradle command: clean test aggregate
I cannot figure out what is wrong since I did nothing else but updating the IDE. Maybe someone has a hint?
Thanks in advance,
Martin
I ran into the same problem when I was following the example in the article mentioned in your comment. In my case (without using an IDE) it seemed to be a out-of-date dependency (which was renamed).
Try changing the dependency 'net.serenity-bdd:browse-the-web' to 'net.serenity-bdd:serenity-screenplay-webdriver' in build.gradle.
My groovy file contains:
#Grapes([
#Grab('org.codehaus.groovy.modules.http-builder:http-builder:0.7'),
#Grab('org.apache.httpcomponents:httpmime:4.5.1')
])
.......code
I am trying to compile groovy and java code. But I am getting below error:
java.lang.RuntimeException: Transform groovy.grape.GrabAnnotationTransformation#69bda33a cannot be run
This works for me, note that I did change HttpBuilder to v.0.7.1:
#Grapes([
#Grab(group='org.codehaus.groovy.modules.http-builder', module='http-builder', version='0.7.1'),
#Grab(group='org.apache.httpcomponents', module='httpmime', version='4.5.1')
])
Likely way too late for you to care, but I saw the same error just now.
I suspect the problem is that the #Grab annotation can't take effect because Maven is controlling the dependencies, or perhaps because Maven is trying to compile both Groovy and Java code, and the class loader created by the #Grab annotation can't influence the Java code.
Upshot is, I suspect you (and I) need to move the dependency out of the Groovy class in question, and put it into the pom.xml file Maven is using.
One of my project requires Java 1.8, but sometimes we didn't notice we are using older java so that we will get some strange errors.
I want to add the checking in build.gradle, so that when we run any task, it will firstly check the version, and prints error and quit immediately.
I tried to add the checking directly in build.gradle on the first line, but it still do some others tasks e.g. (clean, compileJava) before the checking happens, when I run:
$ ./gradlew
How to do it correctly?
If you put the check very early in your build lifecycle (plain check in the beginning of your build.gradle file or in the apply method of a plugin) you shouldn't see any tasks executed.
you can use JavaVersion enum for that which is part of the gradle api:
if(JavaVersion.current() != JavaVersion.VERSION_1_8){
throw new GradleException("This build must be run with java 8")
}
The accepted answer is nice however it could be improved a little bit by making it more generic. Indeed instead of comparing the current version with an explicit version, we could rely on the value of targetCompatibility instead (assuming it has been set properly) as next:
if (JavaVersion.current() != project.targetCompatibility) {
throw new GradleException("The java version used ${JavaVersion.current()} is not the expected version ${project.targetCompatibility}.")
}
I am looking for a simple way write short shell scripts that call into jar files.
Having to keep track of (and installing) all those jar files for the runtime classpath partly defeats the purpose using a script (as opposed to building a runnable jar file in Eclipse). I'd like Maven (or something equivalent) to manage this.
Image:
#!/usr/bin/the-cool-shell
use org.apache.commons/lang/3.0.0
use org.json/json
import org.json.*;
new JSONObject("{}");
And this should get the required artifacts from Maven automatically (at basically zero overhead after downloading it for the first time).
What are my options?
If you were using Groovy and Groovy Shell you could be using the Grape infrastructure.
#!/usr/bin/env groovy
#Grab( 'log4j:log4j:1.2.14' )
import org.apache.log4j.Level
import org.apache.log4j.Logger
def logger = Logger.getLogger(GroovyShell.class)
Logger.rootLogger.level = Level.INFO
logger.info 'I am using the Log4j library by using Grape'
As for your exact example this would work:
#!/usr/bin/env groovy
#Grapes([
#Grab('org.apache.commons:commons-lang3:3.0'),
#Grab('org.json:json:20090211')
])
import org.json.*
new JSONObject('{}')
In this case I was using the Groovy syntax but ordinary Java syntax is also fine.
Taken from the Javadoc of #Grapes annotation:
Sometimes we will need more than one grab per class, but we can only add
one annotation type per annotatable node. This class allows for multiple
grabs to be added.
You could try Gradle, it's a build management tool, but it uses Groovy for its build scripts, and it uses the Maven dependency model. So your script could be a Gradle 'build' script, that just did something different than building software.