@Russ_Thomas and @Brandon_Hein
Thank you for your responses.
Yes, I am referring to parameterized Test Objects. I used the term âvariablesâ in the Test Object since it has Variables and Variables (Script) tabs which is where we define the parameters and their default values - but I really meant âparametersâ. My apologies for any confusion caused. I have updated the title of the post accordingly.
Also, my questions are in context of Web Service API tests (not UI tests).
Here are more details with an example which (hopefully) clarifies what I am asking:
I have a parameterized Test Object with two parameters defined (âExternalIPâ and âExpectedResponseStatusCodeâ) with values assigned in its Variables tab as shown in the screen shot below:
âExternalIPâ is referenced in the argument for the GET command (see above screen shot) while âExpectedResponseStatusCodeâ is referenced in the verification code of the Test Object (which also prints out the values of the ExternalIP and ExpectedResponseCode that it gets from the request) as shown in the code below:
import static org.assertj.core.api.Assertions.*
import com.kms.katalon.core.testobject.RequestObject
import com.kms.katalon.core.testobject.ResponseObject
import com.kms.katalon.core.webservice.keyword.WSBuiltInKeywords as WS
import com.kms.katalon.core.webservice.verification.WSResponseManager
import groovy.json.JsonSlurper
import internal.GlobalVariable as GlobalVariable
RequestObject request = WSResponseManager.getInstance().getCurrentRequest()
println('ExternalIP = ' + request.variables.get('ExternalIP'))
println('Expected response status code = ' + request.variables.get('ExpectedStatusResponseCode'))
ResponseObject response = WSResponseManager.getInstance().getCurrentResponse()
println('Response status code = ' + response.statusCode)
WS.verifyResponseStatusCode(response, request.variables.get('ExpectedStatusResponseCode'))
I have a Test Case which calls Send Request and Verify on the above Test object.
The Test Case has the same two parameters with values assigned in its Variables tab - but values are different from that of the corresponding parameter in the Test Object.
Assume that the GET method is expected to return status code of 200 for the IP in the Test Object (100.100.100.100) and 504 for the IP in the test case (200.200.200.200).
When I run the test case, response code is 200 instead of 504. This indicates that the test used the parameter values in the Test Object and ignored those in the Test Case - this is confirmed in the output of the println statements in the Console log (see below).
Log Viewer (shows the values of the variables in the Test Case at the time of sending request to Test Object)
Console Log (after test run):
2022-04-04 14:23:26.852 INFO c.k.katalon.core.main.TestCaseExecutor - --------------------
2022-04-04 14:23:26.858 INFO c.k.katalon.core.main.TestCaseExecutor - START Test Cases/Get HSM Connection Status Parameterized URL (AKS ExternalIP in Test Object, overridden in TC, verification in TestObject)
2022-04-04 14:23:27.310 INFO c.k.katalon.core.main.TestCaseExecutor - (Default) ExternalIP = 20.85.155.8
2022-04-04 14:23:27.327 INFO c.k.katalon.core.main.TestCaseExecutor - (Default) ExpectedResponseStatusCode = 504
2022-04-04 14:23:27.848 DEBUG idden in TC, verification in TestObject) - 1: sendRequestAndVerify(findTestObject(âHSM-GetHSMConnectionStatus - AKS - Parameterized-ExternalIP from GVarâ, [âExternalIPâ:AKSExternalIP, âExpectedResponseStatusCodeâ:ExpectedResponseStatusCode]))
log4j:WARN No appenders could be found for logger (org.apache.http.client.protocol.RequestAddCookies).
log4j:WARN Please initialize the log4j system properly.
2022-04-04 14:23:30.152 INFO c.k.k.core.webservice.common.HarLogger - HAR: C:\Users\sp185338\AppData\Local\Temp\Katalon\Test Cases\Get HSM Connection Status Parameterized URL (AKS ExternalIP in Test Object, overridden in TC, verification in TestObject)\20220404_142321\requests\main\0.har
2022-04-04 14:23:30.329 INFO c.k.k.core.main.WSVerificationExecutor - --------------------
2022-04-04 14:23:30.329 INFO c.k.k.core.main.WSVerificationExecutor - START Verification
2022-04-04 14:23:30.647 DEBUG testcase. - 1: request = getInstance().getCurrentRequest()
2022-04-04 14:23:30.664 DEBUG testcase. - 2: println("ExternalIP = " + variables.get(âExternalIPâ))
ExternalIP = 100.100.100.100
2022-04-04 14:23:30.671 DEBUG testcase. - 3: println("Expected Response status code = " + variables.get(âExpectedResponseStatusCodeâ))
Expected Response status code = 200
2022-04-04 14:23:30.673 DEBUG testcase. - 4: response = getInstance().getCurrentResponse()
2022-04-04 14:23:30.674 DEBUG testcase. - 5: println("Response status code = " + statusCode)
Response status code = 200
2022-04-04 14:23:30.685 DEBUG testcase. - 6: verifyResponseStatusCode(response, variables.get(âExpectedResponseStatusCodeâ))
2022-04-04 14:23:30.714 INFO c.k.k.core.main.WSVerificationExecutor - END Verification
2022-04-04 14:23:30.747 INFO c.k.katalon.core.main.TestCaseExecutor - END Test Cases/Get HSM Connection Status Parameterized URL (AKS ExternalIP in Test Object, overridden in TC, verification in TestObject)
What I want in this scenario (where the same parameter(s) are defined with different values in the Test Case and Test Object) is the opposite of the current behavior - i.e. test should use the parameter values from the Test Case - instead of those in the Test Object. In other words, Test Case parameter values should âoverrideâ the test object parameter values if present and non-null. So in the above example, the test should use the ExternalIP defined in the Test Case (200.200.200.200) and should return a status code of 504âŚ
So the question is: Does Katalon support a workflow to yield the desired result above? If so, how?
NOTE: I am already aware that Katalon supports execution profiles where you can define global variables - which the parameters in the Test Object (or the Test Case) can be bound to. However, that approach does not always work well in some parameterized testing scenarios - for example, when the number of combinations of parameters to be tested is significant). The ability to override parameter values from the test case would be a better option in this case (IMHO).