Groovy (SoapUI) choose which request are compatible with deployed API and use them - groovy

I want to write SoapUI test cases, which can be run on different versions of API. Before running test case, it needs to find which API versions are deployed. And then choose which request can run on those API versions. API versions are changed every day, so we need that SoapUI test cases can handle different versions.
I wrote simple script in Groovy, which checks deployed API version (major version) on servers and save them in the test suite properties. Also this script checks If we have requests for those versions. It fails when we don't have request for deployed version.
Test Suite Properties looks something like this:
I also have prepared requests for different versions. But now I need to make a Groovy script which will choose appropriate requests. Any idea which is easiest way to do that?
My idea was to make map (apiRequests) with API names as 'keys' and requests names as 'values'. Than use .each and every loop it will get version of that API from Test Suite Properties. I have made this:
API: onboarding, communication, customer-bill, etc.
Requests: Login, Logout, List of inbox messages, See bill history, Retrieve unpaid bills, etc.
def apiRequests=[
'onboarding' : ['Login', 'Logout'],
'customer-bill' : ['See bill history', 'Retrieve unpaid bills'],
'communication' : ['List of inbox messages'],
]
apiRequests.each{k,v->
def apiVersion = testRunner.testCase.testSuite.project.getTestSuiteByName("Independent functions").getTestCaseByName("Get API Version").getPropertyValue("$k")
log.info apiVersion //returns version for api in that loop (e.g. '2' for onboarding api)
}
And now I need to build complete request name (e.g. 'Login - v2'). I think that I can use something like this:
def finalRequest = (v + " -v " + apiVersion)
But this doesn't work because I have more 'values' for one 'key'.
And then I need to disable other requests (different than all finalRequests) ->
Loop - disable: 'Login - v1', 'Login - v3', 'Logout - v1', Logout - v3'; enable: 'Login - v2', 'Logout - v2'
Loop - disable: 'See bill history - v2; enable: 'See bill history - v1'
Loop - etc.
I would like to make this groovy script universal for every test case. So it will run loop for every request stored in 'apiRequests' and If they exist in actual test case, then it choose them and disable others.

This would work what are your looking for -
PS: I assume the properties are added on Project label scope. If you add the properties TestSuite/TestCase lable, change the context.expand('${#TestSuite/TestCase#....}') accordingly.
testRunner.testCase.testSteps.each { k, v ->
if(k.inspect().contains(context.expand('${#Project#onboarding}'))) {
log.info k
v.setDisabled(true)
}
if(k.inspect().contains(context.expand('${#Project#communication}'))) {
log.info k
v.setDisabled(true)
}
if(k.inspect().contains(context.expand('${#Project#customer-bill}'))) {
log.info k
v.setDisabled(true)
}
}
return
PS:
I would suggest to change the value of your property with adding v as version before the version number like you named your testStep name - Login - v1 , Login - v2 etc.
So the property would look like -
|Name | Value |
|----------------------|
|onboarding | v2 |
|communication | v3 |
|customer-bill | v1 |
At any case the above code ll work.

Related

Selecting endpoints dependent on which level to run tests

I have a bit of structural dilemma in soap. When running tests, it can be possible to run tests at project, test suite or test case level.
Now currently what happens is that we can run a whole project via project level and it will display a prompt box to select an endpoint (through a project level setup script and produces a project report using the project level tear down script).
However, it may be possible that the tester may not want to run a whole project and only wants to run a test suite or even a test case. Now it may be possible that the tester may only want to run only a test suite or even only a test case. Now it would be a hassle disabling suites or cases you don't want to run.
Now the problem i have is that if I start putting prompt boxes to select endpoints at suite or case level, everytime we hit a suite or case, it will always ask for an endpoint. Another thing is that I am thinking not creating suite or test case reposts because if running many suites or cases one by one, it is just an overkill on reporting.
I like your thinking on this, but I was speaking with my professional colleague and what we're thinking is this:
Add the below code for all test suites and test case level in their relevant setup scripts where it asks for endpoint (this is same code used in project set up script for selecting endpoint):
import com.eviware.soapui.support.*
def alert = com.eviware.soapui.support.UISupport
def urls = []
project.properties.each
{
if (it.value.name.startsWith("BASE_URL_"))
{
urls.push(it.value.name.replace("BASE_URL_", ""))
}
}
def urlName = alert.prompt("Please select the environment URL", "Enter URL", urls)
if (urlName)
{
def url = project.getPropertyValue("BASE_URL_" + urlName)
def urlBase = "BASE_URL_" + urlName
project.setPropertyValue("BASE_URL", url)
switch (urlBase){
case "BASE_URL_TEST":
project.setPropertyValue("DOMAIN_NAME", "TEST");
break;
case "BASE_URL_STAGE":
project.setPropertyValue("DOMAIN_NAME", "STAGE");
break;
default:
project.setPropertyValue("DOMAIN_NAME", "NO DOMAIN");
break;
}
}
else
{
log.warn 'haven\'t received user input'
log.warn 'No base URL is selected or cancelled, try again'
assert false
}
Now what we add is the following and we may need to use properties but again see what you think is best:
If test is ran at project level, it will prompt to select endpoint through project setup script but it will not ask for selecting endpoint through test suite or test case setup script. So it's only a single endpoint selection
If test is ran at suite level, it will prompt to select endpoint through project setup script but it will not ask for selecting endpoint through test case setup script. So it's only a single endpoint selection
For running at test case level, well it only runs for that test case so it's at the lowest level as it asks for an endpoint for that test case.
We can't have setup scripts disabled at any level because there maybe over code in those setup script that will need to be exectued, we just need a way to say depending on which level, don't ask for selecting endpoints at lower levels.
Seems complicated to implement but does anyone know best way to implement this or do they even have a better idea than this theory?
Thanks
For a moment, let us assume you get it done for all levels (project, suite, and each case). May be you forgot about the step level ;-)
Do you have any Pros in your approach?, for me, NO.
Cons in your approach:
Each time user executes a test (be it project / suite / any test case), engineer needs to select value from the drop down, which is unwanted though testing against the same server as previous test case & little annoying.
Test execution requires manual intervention each time test execution is invoked.
User Interface is required as drop down being used.
Will be come road block / hurdle for end to end automation or to achieve automation.
Test execution can't done in headless mode. And this is important if you need to use Continuous Integration tools.
Proposed Approach :-
If I have to do the above, I would do the following. That would be clean, damn simple, no such complications would arise that you had mentioned in the long summary.
Looks there are following project properties defined with addresses of the test servers:
BASE_URL_TEST
BASE_URL_STAGE
There is also another project property defined BASE_URL and all the above logic is to allow the user to select the value from above properties to base URL value.
Now all user have to do is change the value for project property BASE_URL. I would think just user have to set one of the below value by hand what he / she needed as (one of them) before proceeding with their tests.
${#Project#BASE_URL_TEST} or
${#Project#BASE_URL_STAGE}
NOTE that a property value can be referred into another property by the use of Property Expansion like above.
With the above, user can set whatever is needed and change only if required or have to change the test server.
No setup script at any level is required any more, and just simply change the value of the property.
Properties are given to make to life simple, which can be used in N number of places and maintain the project easily.
Most Importantly, overcome the Cons mentioned in the beginning.
It is general practice that SoapUI is used to design the tests, and SOAPUI_HOME/bin/testrunner.bat or .sh utility to execute the tests in command line mode and that is the way to achieve Continuous Integration.
That's why use of properties helps here to achieve the above without any issues.
Even simple:
Just have one project property BASE_URL (remove others), user have to just edit the property value and have the test server name / IP address and is done for once, say http://testjuniper. Isn't it dead simple?
And I believe, the engineer would definitely know which server he / she is using to execute the tests.
Having said that, now user do not have to bother at all, irrespective of executing a project / suite / test case, as long as testing is carried out against the same server / environment.
Once, the test execution is finished against TEST environment, the engineer may move on to other environment say STAGING, just change BASE_URL property value accordingly.

How to verify if values are updated or not by API using groovy in soap ui

I am using soapui and groovy for api automation and assertion.
Have one API which updates user profile data. i.e update username,firstname,lastname etc.
What is best way to verify that if data is updated or not after run update api. In groovy is there any way by which I can store previous data from API response then run update api and again check response and finally compare previous response and latest one?
What I have tried it comparing values which I am going to sent via API and values which API returns. If both equal then assume that values update. But this seems not perfect way to check update function.
Define a test case level custom property, say DEPARTMENT_NAME and value as needed.
Add a Script Assertion for the same request test step with below script:
//Check if the response is received
assert context.response, 'Response is null or empty'
//Parse text to json
def json = new groovy.json.JsonSlurper().parseText(context.response)
log.info "Department name from response ${json.data.name}"
assert json.data.name == context.expand('${#TestCase#DEPARTMENT_NAME}'), 'Department name is not matched'
You may also edit the request, and add the value as ${#TestCase#DEPARTMENT_NAME} instead of current fixed value XAPIAS Department. So that you can just change the value of department name at test case level property, the same is sent in the request and the same is verified in the response.
Use JDBC teststep to run query directly into database:
Use Xpath assertion to Validate your Update API
Assertion 1
/Results/ResultSet[1]/Row[1]/FirstName
Expected result
Updated FirstName
Assertion 2
/Results/ResultSet[1]/Row[1]/LastName
Updated Last Name
In our project we do it in this way:
First we execute all the APIs.
Then we Validate all the new/updated data in database in DB Validation testcase.
Works well in highly integrated environment as well.

How to use nested paramter in SoapUI context.expand expression?

My use case is that I want to do a bulk update of request bodies in multiple SoapUI projects.
Example of request body.
{
"name": "${#TestSuite#NameProperty}"
"id": "${#TestSuite#IdProperty}"
}
I want to expand the property ${#TestSuite#NameProperty} through Groovy, and get the value stored at TestSuite level then modify it as necessary.
Suppose I have 50 test steps in my test case and I want to expand the request for each one from Groovy script. To expand a specific test steps, I would pass the test Steps's name. For example:
expandedProperty = context.expand('${testStep1#Request}')
But, how can I achieve the same, if I wanted to iterate over all 50 test steps? I tried to used a nested parameter inside the context.expand expression, but it did not work. For Example:
currentTestStepName = "TestStep1"
expandedProperty = context.expand('${${currentTestStepName}#Request}')
This only returned me the expanded request from the test step right above it (where I am running the groovy script from) rather than the "TestStep1" step. ( Which is madness!)
Also, context.expand only seems to work while executing via Groovy script from the SoapUI workspace project. Is there and other way, or method similar to context.expand which can expand the properties like "${#TestSuite#NameProperty}" during headless execution? Eg: A groovy compiled jar file imported in SoapUI.
Thanks for any help in advance!
You can use context.expand('${${currentTestStepName}#Request}') way to get it.
There are other approaches as well, which does not use context.expand.
In order to get single test step request of any given test step:
Here user passes step name to the variable stepName.
log.info context.testCase.testSteps[stepName].getPropertyValue('Request')
If you want to get all the requests of the test case, here is the simple way using the below script.
/**
* This script loops thru the tests steps of SOAP Request steps,
* Adds the step name, and request to a map.
* So, that one can query the map to get the request using step name any time later.
*/
import com.eviware.soapui.impl.wsdl.teststeps.WsdlTestRequestStep
def requestsMap = [:]
context.testCase.testStepList.each { step ->
log.info "Looking into soap request step: ${step.name}"
if (step instanceof WsdlTestRequestStep) {
log.info "Found a request step of required type "
requestsMap[step.name] = context.expand(step.getPropertyValue('Request'))
}
}
log.info requestsMap['TestStep1']
Update :
If the step that you are interested is REST step, use below condition instead of WsdlTestRequestStep in the above.
if (step instanceof com.eviware.soapui.impl.wsdl.teststeps.RestTestRequestStep) { //do the stuff }

Transfer Groovy script response to properties in SOAP UI 5.21

Can any one know how to transfer the groovyscript response into the properties step of SOAP UI. I am trying to generate the random numbers using the groovy script, and when i am gettign the random generated numbers how do i transfer that value to properties in soap ui which can be used for the TCs as a parametered value.
TIA
To make it simple,
Use below code to store any value on,
test case level custom properties:
testRunner.testCase.setPropertyValue("propertyName","value");
test suite level custom properties:
testRunner.testCase.testSuite.setPropertyValue("propertyName","value");
project level custom properties:
testRunner.testCase.testSuite.project.setPropertyValue("propertyName","value");
Use below code to check whether value stored successfully on runtime:
test case level:
log.info testRunner.testCase.getPropertyValue("propertyName");
test suite level:
log.info testRunner.testCase.testSuite.getPropertyValue("propertyName");
project level:
log.info testRunner.testCase.testSuite.project.getPropertyValue("propertyName");
Use below code to use the property value inside anywhere on,
test case level:
${#TestCase#propertyName}
test suite level:
${#TestSuite#propertyName}
project level:
${#Project#propertyName}
global level:
${#Global#propertyName}
Here you go:
The below groovy script code snippet will generate a random number and set the value into to a test case level custom property, say PROPERTY_NAME.
Groovy Script
context.testCase.setPropertyValue('PROPERTY_NAME', (Math.abs(new Random().nextInt()) + 1).toString())
In the same test case, it can be accessed in any test requests as ${#TestCase#PROPERTY_NAME}
EDIT: Based on the change you wanted while above original code works though
def a = 9
def AccountName = ''
(0..a).each { AccountName = AccountName + new Random().nextInt(a) }
context.testCase.setPropertyValue('Property_Name', AccountName.toString())
Even you achieve the same thing using below (just updated value in nextInt() to the first answer)
context.testCase.setPropertyValue('PROPERTY_NAME', (Math.abs(new Random().nextInt(999999998)) + 1).toString())

Test JSF application on multiple servers with same JMeter test script

At the moment we are developing an application and deploying it in my local machine. And now I'm doing a load test using jmeter and it runs without a issue. The problem I'm getting is when I try to run the same test on a different machine with a different server it doesn't work.
And I observed that html element id's are different on different servers with JSF.(Issue is form submissions are not working). Is there a way to overcome this issue with jmeter since I want to run the same test scripts on different servers.
The process of extracting dynamic values from previous response and adding them to next request is called correlation. JMeter provides variety of Pre Processors and Post Processors to allow modification of requests on-the-fly.
Example use case:
Send a GET request a JSP page which contains a number of inputs
Extract all the inputs names and populate values where required
Populate dynamic fields of next request with values extracted in point 2
Send a POST request
Point 1: No changes to your script required
Point 2:
Add XPath Extractor as a child of GET Request and populate it as follows:
Reference Name: INPUT
XPath Query: //input/#name | //input[#type='hidden']
This extractor will fetch all <input> HTML elements and store it to JMeter Variables as
INPUT_1=javax.faces.ViewState
INPUT_2=loginForm_SUBMIT
INPUT3=...
...
Add a Beanshell Pre Processor as a child of next request with the following code
import java.util.Iterator;
import java.util.Map;
Iterator iter = vars.getIterator();
while (iter.hasNext())
{
Map.Entry e = (Map.Entry)iter.next();
if (e.getValue() != null)
{
if (e.getKey().toString().startsWith("INPUT_") && e.getValue().toString().length() >0)
{
sampler.addArgument(e.getValue().toString(),"VALUE OF YOUR INPUT");
}
}
}
The code above will fetch all variables prefixed with INPUT_ and add it as parameters to your next request.
See How to use BeanShell: JMeter's favorite built-in component guide for more information on Beanshell scripting in Apache JMeter to see what else can be done using Beanshell scripting and using of JMeter objects exposed to Beanshell test elements.

Resources