Debug open wrong source file

[danpoleary]

When debugging a testsuite, with a breakpoint set in one of the testcases, the break occurs, but it opens a completely unreferenced testcase source file.

No errors are thrown, and I can continue execution, but I cannot debug.

Version: 6.3.2
Windows 10

[Russ_Thomas]

Is there anything non-standard about your test case(s)?

I can’t break at ANY step in ANY of my test cases - but I know why, they’re very non-standard:

import ...

public class Test extends com.me.basePage {

  Test() {
    // test steps here
    // No breakpoints work here
  }
}

try {
  // Breakpoints work here
  new Test()
  passThisTest()
} catch(Exception e) {
  // Breakpoints work here
  failThisTest(e.message)
}

Does Katalon always load the same erroneous TC? What does it do if you rename it? Remove it?

[danpoleary]

No, They are all standard.

I will be trying to remove/rename the incorrectly opened one when I have a chance today.

It appears to only occur in situation when 2 test cases are very similarly named.

Will let you know results.

[danpoleary]

Ok, I did some digging, and this occurs if the groovy file has the same Scriptname.

For example. I had a test case called “testlong”, who had the goovy file named Script1561547807805.groovy. I then copied the testcase to the same directory which it called “testlong - copy” I then renamed it “testshort” and made edits. When I debug “testshort” it opens “testlong”. So I looked at the Script file for “testshort”, and it was also called Script1561547807805.groovy.

So I searched for all files named Script*.groovy and sorted them. All the ones that have a duplicate Script name have issues when debugging.

[danpoleary]

Ok, I renamed the underlying groovy files so that they were unique, and the debug issue does not occur.

Lesson learned: do not use Katalon UI copy and past of test cases, unless you ensure the underlying groovy filename is unique by renaming it.

Please Note, that any existing reports will not be unusable if it refers to the old name.

[Russ_Thomas]

Thanks for reporting back, @danpoleary.

@devalex88 @ThanhTo you might want to see if this is repeatable. Seems crazy a user can be put in this position over using basic UI functionality.

[devalex88]

@duyluong @Alice Please try reproducing the issue.

Ok, I did some digging, and this occurs if the groovy file has the same Scriptname.

For example. I had a test case called “testlong”, who had the goovy file named Script1561547807805.groovy. I then copied the testcase to the same directory which it called “testlong - copy” I then renamed it “testshort” and made edits. When I debug “testshort” it opens “testlong”. So I looked at the Script file for “testshort”, and it was also called Script1561547807805.groovy.

So I searched for all files named Script*.groovy and sorted them. All the ones that have a duplicate Script name have issues when debugging.

[danpoleary]

@devalex88 @duyluong @Alice

Further too this. I found that the test case name has much to do with this. If I create a folder called “mytests” then inside create a test cases called “testa”. Then copy that test case to the same folder called “testb” and another copy called “testc”.All thee test cases have the same Script###.groovy filename on the filesystem. Now make minor changes to “testb” and “testc”. Any debugging of “testb” or “testc” will open “testa”. If I rename “testa” to “testd”, then debugging “testb” is ok, but degugging “testc” or “testd” opens “testb”.

I think you can see where I am going. The path and sort order of folders seems to play a part. It will open the first file with the Script####.groovy that it finds.