In my main test case ,I have used
WebUI.callTestCase(findTestCase(‘TC1’),[(‘var1’):var1],FailureHandling.STOP_ON_FAILURE)
I have defined var1 under variables tab for main test .
In TC1 script,Do I again mention var1 value under variables section.Is it required
Without defining again in TC1 itself my scrip is working and passed.
You can just try it and see.
You don’t need to ask to others.
F.Y.I
As for WebUI.callTestCase(TestCse, ["var1": var1]) invokation, the “Variables” tab has nothing to do with it.
I suppose you are not convinced that a call WebUI.callTestCase(findTestCase(‘TC1’),[(‘var1’):var1]) has nothing to do with the Variables tab of Test Case named main, and that it has nothing to do with the Variables tab of Test Case named TC1.
I would show you an evidence.
I have made a Katalon project named “test” which contains 2 Test Cases
Test Cases/mainTest Cases/TC1The main has the code as follows:
import static com.kms.katalon.core.testcase.TestCaseFactory.findTestCase
import com.kms.katalon.core.webui.keyword.WebUiBuiltInKeywords as WebUI
WebUI.callTestCase(findTestCase("TC1"), ["var1": "Hello, world"])
The Variables tab of the main test case is totally empty:
Test Case TC1 has the following code:
System.out.println("var1=" + var1)
The TC1 has the Variables tab totally empty as well.
When I run the main, it emitted the following message in the Console:
2023-01-24 12:57:13.045 INFO c.k.katalon.core.main.TestCaseExecutor - --------------------
2023-01-24 12:57:13.054 INFO c.k.katalon.core.main.TestCaseExecutor - START Test Cases/main
2023-01-24 12:57:14.041 INFO c.k.katalon.core.main.TestCaseExecutor - --------------------
2023-01-24 12:57:14.046 INFO c.k.katalon.core.main.TestCaseExecutor - CALL Test Cases/TC1
var1=Hello, world
2023-01-24 12:57:14.114 INFO c.k.katalon.core.main.TestCaseExecutor - END CALL Test Cases/TC1
2023-01-24 12:57:14.114 INFO c.k.katalon.core.main.TestCaseExecutor - --------------------
2023-01-24 12:57:14.148 INFO c.k.katalon.core.main.TestCaseExecutor - END Test Cases/main
Test case main ran fine. The value Hello, world was passed from the main to the TC1.
This is enough to show you that the Variables tab has nothing to do with the callTestCase().
I would tell you what’s going on internally.
When I finished running the main, I found a file test/Libs/TempTestCase1674532629355.groovy under the project folder, which looks like:
import com.kms.katalon.core.main.TestCaseMain
import com.kms.katalon.core.logging.KeywordLogger
import com.kms.katalon.core.testcase.TestCaseBinding
import com.kms.katalon.core.driver.internal.DriverCleanerCollector
import com.kms.katalon.core.model.FailureHandling
import com.kms.katalon.core.configuration.RunConfiguration
import com.kms.katalon.core.webui.contribution.WebUiDriverCleaner
import com.kms.katalon.core.mobile.contribution.MobileDriverCleaner
import com.kms.katalon.core.cucumber.keyword.internal.CucumberDriverCleaner
import com.kms.katalon.core.windows.keyword.contribution.WindowsDriverCleaner
import com.kms.katalon.core.testng.keyword.internal.TestNGDriverCleaner
DriverCleanerCollector.getInstance().addDriverCleaner(new com.kms.katalon.core.webui.contribution.WebUiDriverCleaner())
DriverCleanerCollector.getInstance().addDriverCleaner(new com.kms.katalon.core.mobile.contribution.MobileDriverCleaner())
DriverCleanerCollector.getInstance().addDriverCleaner(new com.kms.katalon.core.cucumber.keyword.internal.CucumberDriverCleaner())
DriverCleanerCollector.getInstance().addDriverCleaner(new com.kms.katalon.core.windows.keyword.contribution.WindowsDriverCleaner())
DriverCleanerCollector.getInstance().addDriverCleaner(new com.kms.katalon.core.testng.keyword.internal.TestNGDriverCleaner())
RunConfiguration.setExecutionSettingFile('/var/folders/7m/lm7d6nx51kj0kbtnsskz6r3m0000gn/T/Katalon/Test Cases/main/20230124_125709/execution.properties')
TestCaseMain.beforeStart()
TestCaseMain.runTestCase('Test Cases/main', new TestCaseBinding('Test Cases/main',[:]), FailureHandling.STOP_ON_FAILURE , false)
Katalon Studio generated this .groovy file out of the source code of Test Cases/main.
If you read the code, you would find that the method runTestCase(String, TestCaseBinding) of the com.kms.katalon.core.main.TestCaseMain class is the entry point into the drama.
The source of this this class is published at
At the line#136,
public static TestResult runTestCase(String testCaseId, TestCaseBinding testCaseBinding,
FailureHandling flowControl, boolean isMain, boolean doCleanUp) throws InterruptedException {
Thread.sleep(DELAY_TIME);
InternalTestCaseContext testCaseContext = new InternalTestCaseContext(testCaseId);
testCaseContext.setMainTestCase(isMain);
return new TestCaseExecutor(testCaseBinding, engine, eventManager, testCaseContext, doCleanUp)
.execute(flowControl);
}
The fragment new TestCaseExecutor(testCaseBinding, engine, ... is important.
What is the engine variable?
If you read the source of this class carefully, you would find the engine is the instance of the Groovy language runtime.
Now lets look at the source of WebUI.callTestCase() keyword:
You will find this fragment at Line#58:
TestResult result = TestCaseMain.runTestCase(calledTestCase.getTestCaseId(), new TestCaseBinding(
calledTestCase.getTestCaseId(), binding), flowControl, false, false)
You should note that the key value pair you specified (["var1": xxxx]) is transformed to be an instance of TestCaseBinding class.
Please note that the Keyword WebUI.callTestCase(TestCase, Binding) does just similar to the auto-generated source of Test Cases/main. It calls TestCaseMain.runTestCase(String testCaseId, TestCaseBinding binding)
Now you will see how the main script passes a key-value pair ["var1":"Hello, world!"] to the TC1 script. The name-value pair is carried around in an instance of TestCaseBinding class.
The “Variables” tab of test case is no relevant to the callTestCase() keyword. The “Variables” tab is all about Data-drivin testing, as @ThanTo mentioned at Parameters in the called test case should not be displayed underlined - #3 by ThanhTo
I am afraid that the Katalon’s official documentation about “Test Case Variables”:
is poorly written. This document is not describing how the product is implemented correctly.
I believe that this document confuses many users. In fact, I was confused by this document for years just as @janani.mariappan is.
→ @vu.tran