https://gradle.com/ logo
Join Slack
Powered by
Hi! I have a project that was originally using Mav...
# community-support
s
Hi! I have a project that was originally using Maven. I converted it to Gradle, and the tests that require a Java agent are now failing. The agent itself adds hooks to JUnit 4 core classes, and it appears that Gradle is loading these into the class cache before my agent gets a crack at them. Consequently, all of my modifications are lost. Is there a way to prevent Gradle from caching these classes? I got this feedback from the author of Byte Buddy:
Copy code
Normally, the JVM disables its class cash if an agent is detected. It seems like Gradle is lacking such detection.
v
How do you register the agent? If you do it using jvmargs, there shouldn't be a problem imho
s
Copy code
test {
  jvmArgs "-javaagent:${classpath.find { it.name.contains('junit-foundation') }.absolutePath}"
}
Running the equivalent process in Maven produces the expected results - the agent is able to install the JUnit 4 hooks, and the tests run successfully.
v
Yeah, that should be fine I think. Don't know why it should not work, unless I misunderstood something. Can you share an MCVE?
s
That could take a bit of time to assemble. This is the only Gradle project I have at the moment, and it definitely doesn't qualify as "minimal".
v
Well, is it shareable at least? 🙂
s
The tests that don't work in the Gradle version of the project are the JUnit tests. (These are currently all disabled so that I could actually publish a release.)
v
Huhg, I didn't expect to find a build script that was created 2017 when you said you converted the project from Maven and now the tests do not work. 😄
s
This PR enabled the JUnit "happy path" test. When executed in Maven, all tests work as expected.
I was just hoping I had overlooked some Gradle configuration related to Java agents, but I haven't found anything.
v
There should nothing be needed besides just setting the jvmarg
s
If necessary, I can see about assembling a minimal repro case. It'll take me a bit of time, though.
The agent is definitely getting invoked, but the JUnit 4 hooks that it's supposed to install aren't there.
Under Maven, everything works.
v
I removed all 
@Ignore
in 
JUnitModelTest
and executed it. I got 70 of 71 passed and 1 failure
s
Hmmm... Which test passed? Is it the first test to get run?
v
JsUtilityTest.testInjectGlueLib
is the one that failed with "Response code 500. Message: Could not start a new session.". All others are green
s
That test is a strange one anyway. What platform are you running on? I'm stuck on Windows 10
v
Me too at this box, work computer
s
Running in Eclipse with 
buildship
plugin
v
IntelliJ here
Oh wait, somehow it executed testNG instead of test if I see it correctly
s
Yeah, most of the tests are TestNG. The framework also supported JUnit 4, so there are a handful of tests for that, too.
The project makes the JUnit tests dependent on the TestNG tests.
A one-line change in 
build.gradle
would remove that dependency.
I just pushed the change to the PR to remove the dependency on TestNG
v
Nah, I just execute with 
-x testNg
, not problem 🙂
Due to the one failed 
testNg
test and the dependency from 
test
to 
testNg
it did not even try the JUnit tests in my first try
s
Ah... Now the real fireworks begin!
The error is this:
Copy code
com.nordstrom.automation.selenium.exceptions.InitialPageNotSpecifiedException: No initial page has been specified
	at app//com.nordstrom.automation.selenium.core.TestBase.getInitialPage(TestBase.java:93)
	at app//com.nordstrom.automation.selenium.core.ModelTestCore.testBasicPage(ModelTestCore.java:32)
	at app//com.nordstrom.automation.selenium.junit.JUnitModelTest.testBasicPage(JUnitModelTest.java:22)
This indicates that the hooks that are supposed to start the Selenium Grid and instantiate a driver didn't get called.
v
And what did Rafael say why this should be a Gradle problem?
s
If you run 
./mvn-build.sh -b htmlunit
, the first set of tests that run are the JUnit 4 tests. They pass as expected.
The quote I posted is verbatim from his response.
(BTW - I run in MINGW64)
v
Well, that quote was
Normally, the JVM disables its class cash if an agent is detected. It seems like Gradle is lacking such detection.
But I totally don't get what he could mean. Gradle is not a JVM. It start a separate test process where the JVM arg is specified and which starts a Gradle class as mainclass which then cares about executing the tests. I don't know where Gradle could somewhere cache some class so that a Java agent doesn't see it. Also the JaCoCo agent works perfectly fine with tests run on Gradle.
s
OK, I'll keep poking at things here to see if I can isolate the source of the issue.
👌 1
2 Views
Open in Slack
PreviousNext
Powered by