How to define parameters with default values for custom keywords


#1

Hi,

normally it should be possible to define default values for Groovy enclosure parameters, shouldn’t it? I thought the syntax was:

def doSomething (something='default value') {
  println something
}

This way I want to avoid that every time I call my custom keyword all parameter values have to be passed, which are identical in about 90% of all cases anyway.

But that code above doesn’t seem to work in Katalon Studio. Am I doing something wrong or is there another way to achieve this? I would like to avoid workarounds like global variables or data-driving etc.

Thanks + regards


#2

Hi Drunda

Taken at face value, I don’t see anything wrong with that code. In my test code, I have a bunch of static methods in Keywords classes setup like this:

  static void doSomething(String something='default value') {
    println something
  }

which works fine.

Russ


#3

Hi Russ,

thanks for your code. I have just tried that out as a Custom Keyword in Katalon Studio in that way:

@Keyword
static void doSomething(String something='default value') {
  println 'something: ' + something
}

Then I created a test case and added that new Custom Keyword in the Manual section. But when I fire, all I get is this:

something:

Obviously Katalon Studio passes the parameter as an empty string but not as null.

On the other hand: If I omit the declaration as String in the Custom Keyword and then add the Keyword in my test case, Katalon Studio in fact pretends to pass the parameter something as null, as it is displayed in the Manual section. And yet, even in this case, exactly the same thing happens:

something:

What’s going wrong with this?

Doesn’t the same thing happen to you?

Thanks + regards


#4

Drunda Nibel said:

On the other hand: If I omit the declaration as String in the Custom Keyword and then add the Keyword in my test case, Katalon Studio in fact pretends to pass the parameter something as null, as it is displayed in the Manual section. And yet, even in this case, exactly the same thing happens:

something:

Even in the Script section of the Test Case I can see the value as null:

CustomKeywords.'ownutils.CommonUtilities.doSomething'(null)

#5

And another question in this context:
Is it possible to provide the user of the Manual test section with a list of possible input parameters for a Custom Keyword in the form of an enum field?


#6

Hi Drunda

What’s going wrong with this?

No idea. Is there some kind of import missing?

Doesn’t the same thing happen to you?

No.

I should mention though, I don’t use @Keyword and I don’t call my Keyword methods from Manual view – I use Script view:

import mykeywordstuff
...

doSomething()

#7

Hi Russ,

out of pure curiosity and because I am still at the beginning to create an appropriate workflow for the specific needs in our company: In which section of Katalon Studio do you create the code for your Keyword mehods? And what are your specific benefits of your approach not to use this inbuilt @Keyword support for repeatedly testing steps? So far I have the impression that the Manual view can simplify a lot and also displays the processes much more clearly, even if you feel at home in the scripting area.

Regards


#8

In which section of Katalon Studio do you create the code for your
Keyword mehods?

In the Keywords section of the Tests Explorer.

The ManualView and the calling convention works fine for non-programmers, but frankly, for programmers, it’s too high-level.

And what are your specific benefits of your approach not
to use this inbuilt @Keyword
support for repeatedly testing steps?

I don’t personally like the syntax used to access the keywords - it’s too lengthy/wordy. Evidenced by how difficult it is to read them in the dropdown in ManualView.

It’s basically adding a layer on top of classes/methods I don’t use, need, or find helpful. I define a keyword (method) called doSomething and call a method called doSomething. Easy. Efficacious.

So far I have the impression that
the Manual view can simplify a lot and also displays the processes much
more clearly, even if you feel at home in the scripting area.

That’s completely fine. If it works for you, don’t let me or anyone tell you different. when it stops working for you, you know what to do B)


#9

Here’s what my utils class looks like:

package com.mycompany

import regular.stuff.here

public class utils {
  static void doSomething() {
    // stuff
  }

  static void myComment(String msg) {
    WebUI.comment(">>> >>> >>> " + msg)
  }

}

Then in my test case:

import regular.stuff.here
import static com.mycompany.utils.*

myComment "Calling doSomething..."

doSomething()

#10

Hi Russ,

thanks for this little insight, I understand …

I tried to recreate this on myself as a test and for learning purposes, but encountered two problems:

  1. When I try to import my class with most often used methods statically, I get an error. Does this require the import of another Java class before?

  2. I can’t use the asterisk in

import com.mycompany.utils.*

But I have to write:

import com.mycompany.utils

Otherwise I get an error too. But does this make any difference?

Finally, in order to actually get my predefined default value out of my Keyword method, I discovered that I have to pass absolutely nothing at all, but even not null. Because null seems also to be regarded as a value that overwrites the default value.

But now I wonder, of course, how I should manage that for a method with several more parameters, of which, for example, only the first few should be passed empty and all others with a value? Because I’m also not allowed to call something like this:

com.mycompany.utils.doSomething( , , , 'value4', 'value5', 6)

Do you have a hint for this?


#11

To use a method across multiple test cases as though it were defined locally in each test case file, you need to import the class file statically _and make the methods themselves static._I’m guessing the error was complaining about something like that?

The utils.* syntax means, import every method.

If you don’t use the * and you don’t use static, then you’ll need to create an instance of your utils class and call its methods as members – for little utility methods/helpers, that’s unnecessary and makes your code lengthy for no good reason.

Finally, in order to actually get my predefined default value out of my
Keyword method, I discovered that I have to pass absolutely nothing at
all

Correct. For “optional arguments”, they need always to come last in the list of arguments (or, like in your doSomething example, the only argument) and only gain their “default values” when not supplied at the call site.

Default arguments

Default arguments make parameters optional. If the argument is not supplied, the method assumes a default value.

def foo(String par1, Integer par2 = 1) { [name: par1, age: par2] }

assert foo(‘Marie’).age == 1


  

  

  

Note that no mandatory parameter can be defined after a default parameter is present, only other default parameters.

  

Read the following, starting from the top, paying attention to the syntactic
details. You don’t need to read it all… once you’re getting the
general idea, you can skip from “guide” to treating it as a
“reference”.

http://groovy-lang.org/single-page-documentation.html

As for your last question, search that page for “Varargs”.

Hope this helps.


#12

Hi Russ,

sorry for the delay.

The utils.* syntax means, import every method.

Yes, I was aware of that. But because of the error that occurred with

import com.mycompany.utils.*

I wondered if

import com.mycompany.utils

shouldn’t actually have the same effect? Basically it seems to work that way.

For “optional arguments”, they need always to come last in the
list of arguments (or, like in your doSomething example, the only argument) and only gain their “default values” when not supplied at the call site.

Yes, I had already drawn that conclusion. Unfortunately, this is only of little use to me if sometimes these and sometimes those parameters are to be used with default values.

Anyway, thanks for your help!

Regards


#13

My answer is year late, but this is what worked for me:
When providing variables’ values for your keyword in test, for the variable that should be by default equal to “null” change “Value Type” to “Variable” and in “Value” field provide “null”.