Method code too large

Product Forums Katalon Studio
,
1

I’ve got a couple scripts under my belt and I want to run one of them a few times, so I copied & pasted what I wanted 5 times into a new test case. When I run it, I get the following error:

Test Cases/JJJones x5 FAILED because (of) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
General error during class generation: Method code too large!
java.lang.RuntimeException: Method code too large!
<snip>

Any thoughts as to what it may be? The single time through runs fine. Or is there a more correct way of running a script multiple times? Not a programmer, but a hacker.

1 Like
2

It is interesting! How big is your script?

3

In the Manual view, it’s 1409 lines (items).

4

I have the same issue. When my test case is greater than 1000 lines (items) I get the same Method code is too large! error. This forces me to split it up my test case, even in places I don’t want to. I can find no way around it.

5

This is turning into a mantra it seems…

Take your common test code, turn it into Classes/Methods and store them under Keywords (they don’t need to actually BE keywords, but there’s nowhere else I’ve found that works easily). For example, if you have a page called “my Fabulous page”, make a class called MyFabulousePage and add methods that “wrap” logical parts of the page’s functionality.

Then you can write code like…

MyFabulousPage.navigateTo()

MyFabulousPage.addNewUser("Russ", "!my@secret#pass$word%", "!my@secret#pass$word%")

Login.loginUser("Russ", "!my@secret#pass$word%")

Logout.logout()

All the “test” steps are inside the methods. Plus, this way, you’ll end up with core methods that you’ll reuse on many pages making your tests more robust and reusable.

5 Likes
6

I agree with this idea. Once we have imported all our Selenium Scripts we will convert many repeated procedures into core methods. But this still doesn’t explain why Katalon is telling us that our Methods are too large.

7

Ilya Novak said:

I agree with this idea. Once we have imported all our Selenium Scripts we will convert many repeated procedures into core methods. But this still doesn’t explain why Katalon is telling us that our Methods are too large.

No, you’re right, it doesn’t. (Though it may help to avoid it.)

@KMS: please document what is and is not an acceptable length for a TestCase run() method (which I assume is the method whose length is being complained about).

Why this is important:

Groovy, the chosen language for the Katalon Studio development IDE, is an expressive and (more importantly), dynamic language. What this means is, the language and the objects it may generate can be extended during the execution of and life-time of a program. That being the case, any system that hosts (i.e. “supports”) Groovy which has any hard-wired limits which impacts that capability should make clear what those limits are since it reduces the efficacy of the language at the point of use.

@Ilya Novak Perhaps you should post this on the bugs forum?

Russ

4 Likes
8

Thank you for your suggestion, Russ. It is noted.

9

I’m having the same issue, I have had this same test case run fine in every version of Katalon up until 5.4. I don’t understand why we are losing functionality? I wrote this code back in version 4. something.

10

nice…cut my code in half and now instead of 1300 lines I have 786 and still getting the same error if I roll back to last version of Katalon 5.3.1 it runs fine but 5.4 fails with error:

because (of) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:

General error during class generation: Method code too large!

java.lang.RuntimeException: Method code too large!

at groovyjarjarasm.asm.MethodWriter.a(Unknown Source)

at groovyjarjarasm.asm.ClassWriter.toByteArray(Unknown Source)

at org.codehaus.groovy.control.CompilationUnit$16.call(CompilationUnit.java:815)

at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1053)

at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:591)

at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:569)

at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:546)

at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)

at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)

at com.kms.katalon.core.main.ScriptEngine.getScript(ScriptEngine.java:188)

at com.kms.katalon.core.main.ScriptEngine.run(ScriptEngine.java:183)

at com.kms.katalon.core.main.ScriptEngine.runScriptAsRawText(ScriptEngine.java:108)

at com.kms.katalon.core.main.TestCaseExecutor.runScript(TestCaseExecutor.java:295)

at com.kms.katalon.core.main.TestCaseExecutor.doExecute(TestCaseExecutor.java:286)

at com.kms.katalon.core.main.TestCaseExecutor.processExecutionPhase(TestCaseExecutor.java:265)

at com.kms.katalon.core.main.TestCaseExecutor.accessMainPhase(TestCaseExecutor.java:257)

at com.kms.katalon.core.main.TestCaseExecutor.execute(TestCaseExecutor.java:201)

at com.kms.katalon.core.main.TestCaseMain.runTestCase(TestCaseMain.java:86)

at com.kms.katalon.core.main.TestCaseMain.runTestCase(TestCaseMain.java:77)

at com.kms.katalon.core.main.TestCaseMain$runTestCase$0.call(Unknown Source)

at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)

at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)

at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:149)

at TempTestCase1524164206965.run(TempTestCase1524164206965.groovy:20)

at groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:263)

at groovy.lang.GroovyShell.run(GroovyShell.java:518)

at groovy.lang.GroovyShell.run(GroovyShell.java:507)

at groovy.ui.GroovyMain.processOnce(GroovyMain.java:653)

at groovy.ui.GroovyMain.run(GroovyMain.java:384)

at groovy.ui.GroovyMain.process(GroovyMain.java:370)

at groovy.ui.GroovyMain.processArgs(GroovyMain.java:129)

at groovy.ui.GroovyMain.main(GroovyMain.java:109)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)

at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:109)

at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:131)

1 error

11

Same probleme here! I am looking forward for a fix :slight_smile:

Btw: It’s my first time of using Katalon. This bug is defenitly a show stopper.

5 Likes
12

@Felix Hoess

Katalon is still very very functional and has a lot of power. The GUI for writing automation is huge. I broke my test up into 3. I still am capture alot, I just dont like having to back to the page. But this test was a general functionality “smoke test” so it was much bigger then my typical one.

13

Hi All,

I am getting same error when i use data file with more then 500 rows, till 500 rows it works fine. I tested this in 5.2 version and it works fine. This seems to be issue with 5.4. Please confirm if there is going to be fix for this in next version of Katalon.

14

Hi,

Same issue here. Is there a way to get previous Katalon Studio versions (like 5.2 on mac)? I really don’t want to split test cases.

Found out how to download an older version:

Thank you.

15

Hi Katalon Team,

Is this issue going to get fixed in new version ? I validated this in 5.5 and it is still an issue. Is there a workaround/solution available.

Thanks & Regards
Vikas

16

I am also getting the same issue and I deleted some data from excel sheet which I am using as Data input, deleted blank lines and restarted the Kataloan
resolves my issue.

17

I’m on v5.6.1 and getting the issue with 417 line items. I’ll be shrinking my code later as I learn the tool, but this limitation is troublesome to the learning process.

18

A Test Case of Katalon Studio makes a method of a class which runs on Java VM.

The Java Virtual Machine has a limitation that a single method cannot be larger than 64k (65536 bytes) in size. See Method code too large in Groovy & Grails? - Stack Overflow for more info.

Katalon Studio would never, I suppose, become capable of handling a large test case exceeding the Java VM limitation. If you encounter the “Method code too large!” problem, you have no other choice but shrinking your test case code.

I would suggest splitting your large test case into a set of smaller test cases making sure each of them smaller than the JVM limitation. And you add a test case which invokes other worker test cases using WebUI.callTestCase(). 

[ a large test case ]  >>>>> [caller test case]
                                                -> [callee test case 1]
                                                -> [callee test case 2]
                                                -> [callee test case 3]
                                                -> ...
                                                    smaller codes as many as you want

edited at 8 Jan, 2020

… splitting your large test case into a set of smaller test cases … (then re-assemble them) using WebUI.callTestCase()

No. It does not help. I found that WebUI.callTestCase() concatenates the code of callee scripts into the caller to form a single large method. If the caller script has 100 lines of script, and the callee script has 400 lines, then at runtime we will have a single method of 100 + 400 = 500 lines. In terms of JVM method size, this approach does not make any effect.

No need to say, a straight forward refactoring would be
splitting a large Test Case into smaller pieces, and bind them by a Test Suite, if possible.

[ a large test case A]  >>>>> [Test Suite X]
                                                -> [test case 1]
                                                -> [test case 2]
                                                -> [test case 3]
                                                -> ...
                                                    smaller codes as many as you want
3 Likes
19

Upvoted

Kaz, you should make that an article or Tips and Tricks post.

20

Charles, the originator of this discussion, said:

In the Manual view, it’s 1409 lines (items).

How come has he got such a big test case! I was surprised.

Such a mighty test case can not be written by hand. I guess that this big code must have been generated by Web Recorder of Katalon Studio. I can remember how Web Recorder behaves when I start visiting the site http://demoaut.katalon.com/ and navigated through 4 different web pages. In the end the Web Recorder generates a single (fairly large) code as test case. Charles and others possibly used Web Recorder and went through 10 pages, 20 pages or more. A long recording resulted, I guess, 1409 lines.

Web Recorder would generate a big code. That’s OK. That’s the way it works. But one thing, I always regard the generated code as a material, a premature draft, or a sketch which requires careful refinement. I would read the generated code, understand it, and find semantical borders. Then I would split it into a set of code snippets of manageable size.

I am rather afraid that those who are new to Katalon Studio may expect the test case code generated by Web Recorder is near completion. But I swear the code generation is just a start. You have long way to go for continuous rethink and rewriting codes.

1 Like