Ah, certainly your case seems to be a bit more complexed as the Exception you got was
java.lang.NoClassDefFoundError: Could not initialize class internal.GlobalVariable
at com.xxxxxx.basePage.<init>(basePage.groovy:50)
at com.xxxxxx.home.<init>(home.groovy)
at Test Access The Big Four.run(Test Access The Big Four:110)
at com.kms.katalon.core.main.ScriptEngine.run(ScriptEngine.java:194)
...
This is not a simple compilation error. There seems to be more factors to investigate.
You are getting a java.lang.NoClassDefFoundError which does NOT mean that your class is missing (in that case you’d get a java.lang.ClassNotFoundException ). The ClassLoader ran into an error while reading the class definition when trying to read the class.
My thought: if you Libs/internal/GlobalVariable.grooy has the following code:
$WE_ACTIVE = selectedVariables["$WE_ACTIVE"]
then, Groovy lang will try to find a property named WE_ACTIVE somewhere in the internal.GlobalVariable class. Groovy lang will try to find WE_ACTIVE as an instance property as well as an static property. If com.xxxxxx.basePage.<init>(basePage.groovy:50) tries to load the internal.GlobalVarialbe class in a static block, then I presume that the ClassLoader may fail to load it and throw NoClassDefFoundError, because the classloader can not find an instance property named WE_ACTIVE.
Please edit the file with your favorite text editor as follows:
$WE_ACTIVE = selectedVariables['$WE_ACTIVE']
I mean, enclose $WE_ACTIVE with a pair of single quotes, rather than double quites. Save the change, then try running your test. I guess it would run successful. I want to see if this is the case or not.
I meant, in 5.4 Katalon produces that reference (single quotes) and it works fine. In 5.10+ it generates the same line with double-quotes and shoots itself in the foot.
But that’s the point, Kaz, if I edit the file, once it’s edited and I run a test, Katalon will overwrite it and break it again (at least, I’m assuming it would, I’ve never actually tried).
Yes. In Katalon parlance, it’s a “keyword class”, so public class basePage. My Test Cases extend a specific page class, the page class extends basePage.
Line 50 is literally the basePage constructor:
basePage() { ...
The lines before it are field definitions for the class. IOW, nothing weird.
No, it’s not a static block.
Kaz, I really appreciate your forensic analysis – it’s quite extraordinary. However, you don’t need to look further than the error as depicted in the screenshot. When I double-click the error in the Problems panel, Katalon takes me to the GlobalVariable.groovy file and highlights the $WE_ACTIVE just like the screenshot shows (IOW, I didn’t make it blue, that’s Katalon doing that!) And notice it does not include the $ in the highlight… because it thinks $ is the placeholder marker and the problem is the reference it cannot resolve. Well it’s not a reference, it’s the damn name!
To cut this short, there is an alternative to editing the GV file and changing the quotes - I could change the name to be WE_ACTIVE (i.e. get rid of the $). And guess what - that works. No issues. While @devalex88 and I were looking at it, that worked just fine.
The unfortunate thing is, I have good reason to need the $ in the name (it’s meaningful in the AUT and meaningful to reflect it correctly in the Tests).
However, pragmatism will rule the day - if this cannot be fixed in the next “proper” release of Katalon (6.0.4 is not proper in my view) I will alter the name and remove the $.
Thanks for the research, Kaz. It’s much appreciated!
No. Once I have ever tried it in my “$FOO” sample project. Katalon did not overwrite the GlobalVariable.groovy source file which I manually edited "$FOO" to '$FOO' when I run my tests. My test once failed but after edit the GlobalVariable.groovy source it turned to succeed. In order to let it fail again, I had to edit it back to "$FOO" and delete the <projectDir>/bin directory so that Katalon Studio compiles the GlobalVariable.groovy source file.
Yes, I understand it.
The point is clear now to everyone who read this thread.
When you edit a Execution Profile ‘default’ using Katalon Studio’s GUI, the edit result will be saved into this ‘global.glbl’ file in XML format.
After then, when a test runs, Katalon Studio reads all of the <projectDir>/Profiles/*.glbl files and generates a single <projectDir>/bin/internal/GlobalVariable.grooy source file, and compiles it into an executable *.class file.
GUI -> XML -> *.groovy -> *.class
This is the way Katalon Studio works, I suppose.
You have a chance to edit manually the GlobalVariable.groovy file which will not be overwritten by Katalon Studio as far as *.glbl XML files stay the same.
I got this error as i edited the file default.glbl directly in file system. Then i noticed its not listing the variable on typying GlobalVariable. under script.
I opened the same file in Katalon, and removed the variables and added again. It started working.
So I don’t think the Unable to resolve class internal.GlobalVariable error is anything more than a non fatal warning if you see the error right before the lines below in the console output like so:
katalon | /%tmp%katalon_execute%project%your-katalon-project.prj/Include/scripts/groovy/Steps.groovy: 21 Groovy:unable to resolve class internal.GlobalVariable
katalon | Generating global variables...
katalon | Project 'your-katalon-project' opened
However if you get an error complaining about resolving global variables during a test case, then your project has been corrupted somehow and the global variables are not compiling correctly. Dunno what your issue is. I have had this happen and the error prints out like a normal Java stack trace during the execution of a test case.
For many people, including me, the error is probably something else and it seems like the warning about Unable to resolve class internal.GlobalVariable is an actual error causing us pain, probably not.
Reading through this thread you will realize a whole lot of people having issues with specifically running tests through the console and especially Docker. This thread, in my eyes, has become the default thread for, "I don’t know what happened but I saw Unable to resolve class internal.GlobalVariable in the terminal output.
P.prj/Keywords/api/Auth.groovy: 8 Groovy:unable to resolve class internal.GlobalVariable
P.prj/Keywords/api/Parser.groovy: 12 Groovy:unable to resolve class groovy.json.JsonSlurper
P.prj/Keywords/api/Project.groovy: 3 Groovy:unable to resolve class internal.GlobalVariable
P.prj/Keywords/api/RestMethods.groovy: 11 Groovy:unable to resolve class internal.GlobalVariable
P.prj/Test Listeners/DefaultTS.groovy: 6 Groovy:unable to resolve class internal.GlobalVariable
Parsing custom keywords…
P.prj/Keywords/api/Auth.groovy: 8 Groovy:unable to resolve class internal.GlobalVariable
P.prj/Keywords/api/Auth.groovy: 8 Groovy:unable to resolve class internal.GlobalVariable
P.prj/Keywords/api/Project.groovy: 3 Groovy:unable to resolve class internal.GlobalVariable
P.prj/Keywords/api/RestMethods.groovy: 11 Groovy:unable to resolve class internal.GlobalVariable
P.prj/Test Listeners/DefaultTS.groovy: 6 Groovy:unable to resolve class internal.GlobalVariable
P.prj/Keywords/api/Project.groovy: 3 Groovy:unable to resolve class internal.GlobalVariable
P.prj/Keywords/api/RestMethods.groovy: 11 Groovy:unable to resolve class internal.GlobalVariable
See my post here. That is not an error, it is a warning. You get that because in your keywords there are imports for the GlobalVariables class which is not parsed till after the keywords. I get the same and everything works fine, it’s just annoying to see in the console. Could be “fixed” by simply removing those imports and not using GlobalVariables in your keywords or listeners.