Manual view inserts the wrong method signature for overloaded functions

Katalon Computer
8.2.5 Windows 10 Pro

Please let us know what you are using Katalon Studio for?

  1. I build test cases for a company project at work

How would your work be affected if this issue has not been resolved?

  1. I can continue my job, resolving this ticket can boost my performance

Steps to reproduce

manual view doesn’t appropriately handle inserting custom keywords with multiple signatures. e.g. i wrote a function generateDatetimeString() which takes two forms:

public static String generateDatetimeString(String format)
public static String generateDatetimeString(String format, int daysOffset)

so you can either create a datetime (for inserting into forms) either just for today or, for example, a week in the future. unfortunately, katalon will show you both options in Manual view:

image|581.081081081081x250

but when you select one, it’ll only ever insert the first version:

image|342.1550094517958x250

this is incredibly frustrating both for me and my less code-savvy colleagues who rely on my functions to build test cases. because of this bug, i have to create a ridiculous number of functions with ridiculous names that point to specific signatures of my other functions like so:

@Keyword
public static String generateDatetimeStringForToday(String format) {
  return generateDatetimeString(format)
}

this ends up cluttering the namespace and making an already bulky library even harder to read through with even more function names to memorize. and it just looks/feels tacky, both for my library and katalon studio itself.

I tried to reproduce your case.

I wrote a class as Custom Keyword class:

package shaun

import com.kms.katalon.core.annotation.Keyword
import com.kms.katalon.core.webui.keyword.WebUiBuiltInKeywords as WebUI

public class CustomKeyword {

	@Keyword
	public static String generateDatetimeString(String format,
                                                int daysOffset = 1) {
		println "generateDatetimeString(" + format + "," + daysOffset + ")"
	}
}

Here I used a Groovy’s Goodness Parameters with default value, which is different from Java.

I opened a test case in Manual mode and selected the custom keyword.

I found that

  1. The keyword shaun.CustomKeyword.generateDatetimeString in 2 lines in the menu.
  2. The first line corresponds to the method signature with arguments (String format, int daysOffset)
  3. When I opened the “Input” dialog.
    0 was preset as the default value to the 2nd argument daysOffset

@shaun.mitchell

You are frustrated because

consequently you can not set value to the 2nd argument daysOffset.


Now, let’s discuss.

In the class source, you wrote 2 methods. On the other hand, I wrote only 1 method with parameter with default value.

I expected only 1 line of shaun.CustomeKeyword.generateDatetimeString to appear in the menu. But in fact 2 lines appeared. This is inconvenient, I do not like this at all. Anyway, it works as is…

When I select either of 2 lines In the menu, KS only ever insert the version of method signature with 2nd argument daysOffset.

This is better for you, isn’t it? I suppose you could find a way to decrease the number of the method names of your Custom Keyword.


I expected Katalon Studio to respect my code:

.... int daysOffset=1) {

I wanted KS to take 1 as the default value in the GUI.

However I found KS sets 0 as default. KS does not respect my code.

It’s unfortunate. I see that the Manual mode is not every much cultivated.

@Jass
@duyluong

well, i suppose this wasn’t a grand example :stuck_out_tongue: i could just set daysOffset to 0, and the effect is the same. but some functions have versions that take, for example, a String parameter instead of an int or a WebElement instead of a TestObject, and the difference in parameter type results in important differences in behavior. in those cases, it’s literally impossible for anyone using manual mode to take advantage of the multiple signatures which is necessary for utilizing different features.

as a perhaps better example, i’ve got this function that sets the value of a cell in a table which takes two forms:

setTableCellValue(String tableName, String columnName, int row, String value)
setTableCellValue(String tableName, int column, int row, String value)

notice one uses an int to identify the column by its position, and the other uses a String to identify a column by its header. some columns don’t have headers, so you have to identify them by the column position using the 2nd signature. but since katalon only ever inserts the first signature, non-coders who use manual mode simply cannot access the function they need to access, and i have to write a whole new function with an obnoxious name like setTableCellValueByName()

I understand your description. I would agree that the Manual mode of Katalon Studio needs more of brush-ups.


I am afraid, Katalon team would NOT notice this issue because, as Jass wrote, this User Forum is not a gateway to Katalon’s support service.

Even if someone of Katalon notice this, I guess, they would not take this too seriously. Why? — as far as I am aware since its service launch, nobody has ever pointed out what you point out now. They would not be able to appreciate its significance.

@Jass
@duyluong what do you think?


@shaun.mitchell

If you want Katlaon team to make any action to this, you should “submit a ticket” at
https://support.katalon.com/hc/en-us
and call for their serious response.

I am not a Katalon man, and I do not use Manual mode at all. So I am no longer interested in this topic.

Here I see a contradiction at the design level. I think that the KS Manual mode is designed to hide the details of parameters (name, data type) to present a simplified view of keywords for non-coders who tend to fear signature details. But now you have created a lot of signatures. I do not think that your idea will fit into the Manual mode.

@shaun.mitchell

Why not you ask your people to work in the Script mode to make full use of the method signatures you developed?

Otherwise, you should change your design.

I guess, you could design your keyword at the one step higher level of abstraction.

This seems to me to be too low level for non coders. Do they really use these?

I guess non-codes would prefer, for example

insertRowIntoTableFoo(Map<String, String> keyValuePairs) 

Higher level of abstraction would result less number of signatures.

I do actually have a function like that as well :stuck_out_tongue: But sometimes you do need to target a specific cell. If possible, people prefer specifying a cell by column name + row, but some of our columns lack names so you have to use the column index.

I’ve spent hours showing people how to use Script view. And I’ve got years of pretty successful tutoring under my belt, so I have a modicum of confidence in my teaching abilities :stuck_out_tongue: Some people just don’t want to learn how to code, even at a super simplistic level.

If that were the case, then why do they show all of the signatures to the users? That’s a contradiction :stuck_out_tongue: If you want to hide the finer details of extra signatures from users, then you should actually hide all except the first signature. If the goal is to keep confusion to a minimum, showing a user multiple signatures with different javadocs, and then inserting a signature other than the one they clicked on is not how you accomplish that. The non-coders on my team have the ability to distinguish between two functions with the same name but with different javadocs and which take very obviously different but clearly named parameters. The only confusing part for them (and me) was why Katalon didn’t show those parameters in the Input popup after they selected the correct signature.

I would agree with you.

I think that the Manual mode is still to be refined.

I guess that nobody , other than you @shaun.mitchell, has ever devoted much time creating so many custom keywords and tried to list them nicely in the Manual mode menu. Most people use the built-in keywords only and are contented.

I do not use Manual mode at all, and am not interested in it. :stuck_out_tongue_winking_eye:

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.