ContributionsMost RecentMost LikesSolutionsExpand the contained content when expanding dialog box size I often use the 'Clone Test Case' and 'Clone Test Steps' features of ReadyAPI... Both of those open a somewhat small dialog box for all the data that is contained in them. The dialog box for both currently allow you to expand the size of the dialog box. That is all great... However, if you need (or would like) to see more content available for data entry, the impulse to expand the dialog box to allow larger view/entry does not satisfy. All of the data entry areas remain the same size even though the dialog box can expand or shrink. What is the point of expandable dialog box when the content area does not expand or contract with it? I would love to see the width of the single line data entry areas expand with the dialog box size and also the depth of multi-line data entry areas expand from their current limited view of five to as many as you expand the dialog box to. Re: Create assertion 'templates' so you can apply & edit an assertion to multiple test steps Hello mnwill117 just a comment here... I accomplish this now by using an assertion contained in a groovy script... I have one groovy script that contains an assertion. From any testcase in any suite of a project, I can call the one groovy script that contains the assertion. I can modify the assertion across the board in one place. Re: How to escape ampersand in Property Expansion? Hello JohanF , Your xml example shows the name of a property... I was getting a little confused by your question because it sounded like you want to set the value of a property (not property name)... As a minor rule of thumb, it is wise not to allow property names to contain special characters as you are witnessing... These names are being utilized by internal workings of SoapUI and you are begging for issues if you must include special characters for a property name. Property values can have special characters without much issue. Before setting a property name maybe you could scrub it for special characters and eliminate them or replace with inert character (underscore or dash or something). Just my thought... I don't think there is a native solution to what you are encountering. Regards, Todd Re: OS SoapUI: Can it connect and use Cosmos DB Hello jkrolczy I have not connected to Cosmos DB... I have connected to MongoDB by using java client (not supplied by Smartbear) that allowed interaction via Groovy Script. Microsoft supplies a Java db client library for Cosmos DB that would be the first place I look... Regardless, it won't be built into SoapUI or ReadyAPI so you will need a little coding in Groovy Script test step to gain access to Cosmos DB. Just a thought. Regards, Todd Re: Save Groovy output to JUnit report Hello ccarnes I don't think there is a native way to do that... We us a third party tool to keep track of test results... that tool imports JUnit files. Unfortunately, the ReadyAPI JUnit output file did not contain all the data that I wanted to get propagated to the third party tool. We wrote a groovy script that would read the JUnit file and travel the log output file that can be created from running from the CLI. By putting testcase name or step or some key mechanism in the log output file and reading that for each testcase in the JUnit file we were able to put whatever we wanted into the JUnit file. The third party result tracking tool could then import the JUnit file that contained normal formatted output plus the merged content from log that we wanted. As it turns out it was not to painful to accomplish. Just an idea for you. Regards, Todd Re: Accessing database connection string from groovy test step Hello chirangv import groovy.sql.*; import com.eviware.soapui.support.GroovyUtilsPro; def jdbcConnectionName = "your jdbc name defined in environment configuration page"; //log.info " jdbcConnectionName=$jdbcConnectionName"; def groovyUtilsPro = new GroovyUtilsPro(context); def sqlConnection = groovyUtilsPro.getJdbcConnection(jdbcConnectionName); def sql = Sql.newInstance(sqlConnection); def sqlQuery = """ SELECT colname FROM tablename WHERE colname = 'something' """.toString(); log.info " sqlQuery=$sqlQuery"; dbRows = sql.rows(sqlQuery); log.info " dbRows.size()=${dbRows.size()}"; assert dbRows.size() > 0, "Need a row returned but none was... No data found."; dbRows.each { row -> log.info " row.id=${row.id}"; }; Re: GraphQl request : extra quotes added to the Query Variables when the QUery Variables is a property Hello _Oliver_ After four years, this is still occurring... :( I ran upon your stated issue today... A work around is to give a functional shell structure of the Query Variables and use property expansion within that shell... instead of the only Query Variables content of: ${#TestSuite#queryVar} Use this in the Query Variables (after you define queryUUID test suite property): {"testId": "{${#TestSuite#queryUUID}}"} So that the structure is maintained but you parameter replace just the portion that is needed to fulfill the request. Regards, Todd Re: Create Selenium Tests in ReadyAPI Hello Kpm , I have never had good results putting my jar files in the location Smartbear says to... I do not use: ReadyAPI/bin/ext Use: ReadyAPI/lib Where all the other jar files are stored. Exit ReadyAPI and delete or move the selenium jar files you put in ReadyAPI/bin/ext to ReadyAPI/lib then restart ReadyAPI. Remember to rename the originality installed guava jar to guava.ojaro. After you restart ReadyAPI with those changes you should be relieved of the error. Regards, Todd Re: Passing variable as index in property, Groovy Hello jrziggy It looks like this is a little trick situation... you need to expand the 'randomIndex' variable before the whole datasource reference is parameter expanded... The context.expand is operating on a string, so just manipulate it a little bit to get your number in there instead of the variable that references it... be mindful of single quote use versus double quote use below. Simple parameter replacement occurs when double quotes are used. This sample just gets that variable replaced before the whole context.expands the full parameter. result = context.expand( '${DataSourceStationNumber#STATION_NUM::' + "$randomIndex" + '}' ); Regards, Todd Re: Testing RESTful APIs with complex request - Emmanuel Katto Uganda Hello emmanuelkatto23 I have a technique to share but it is not specific to XPath or JSONPath... The technique I employ is to use JsonSlurper (https://docs.groovy-lang.org/latest/html/gapi/groovy/json/JsonSlurper.html). It is very efficient and has allowed me to interrogate every complex JSON structure that I have explored. I only use a groovy test step to make my own assertions from other test step results that contain the actual invoke of an API from an 'HTTP Request' test step and not a 'REST Request' test step. I prefer HTTP Request over Rest Request so that I don't have to import an API to use it (less baggage in my mind). Sample stand alone JsonSlurper code with assert to copy/paste/run into groovy test step... import groovy.json.JsonSlurper; log.info 'Test Step "' + testRunner.runContext.currentStep.name + '" start...'; log.info ""; def String jsonStr = """ { "step_list": [ { "end_date": "2035-09-01T00:00:00", "payments": 12, "sequence": 1 }, { "end_date": "2035-09-01T00:00:00", "payments": 67, "sequence": 2 } ] } """; def jsonSlurper = new JsonSlurper(); def jsonObj = jsonSlurper.parseText(jsonStr); log.info "jsonObj=$jsonObj"; def expectedSize = 2; assert jsonObj.step_list.size() == expectedSize, "Expected step_list size to be $expectedSize but it is = ${jsonObj.step_list.size()}"; log.info "jsonObj.step_list.first()=${jsonObj.step_list.first()}"; log.info "jsonObj.step_list.last()=${jsonObj.step_list.last()}"; def datePattern = "yyyy-MM-dd"; jsonObj.step_list.each { step -> log.info ""; log.info "step=${step}"; def stepDate = Date.parse(datePattern, step.end_date); log.info "stepDate=${stepDate}"; Date lowDate = new Date("08/15/2020"); Date highDate = new Date("10/15/2040"); def nowDate = new Date(); assert stepDate > lowDate, "Expected the step date to be greater than $lowDate but it is $stepDate"; assert stepDate < highDate, "Expected the step date to be less than $highDate but it is $stepDate"; assert stepDate > nowDate, "Expected the step date to be greater than today but it is $stepDate"; def expectedPaymentMinimum = 10; assert step.payments > expectedPaymentMinimum , "Expected the step payments to be greater than $expectedPaymentMinimum but it is ${step.payments}"; if (step == jsonObj.step_list.first()) { log.info "step.sequence=${step.sequence}"; def expectedFirstSequence = 1; assert step.sequence == expectedFirstSequence, "Expected the first step sequence to be $expectedFirstSequence but it is = ${step.sequence}"; }; if (step == jsonObj.step_list.last()) { log.info "step.sequence=${step.sequence}"; def expectedLastSequence = 2; assert step.sequence == expectedLastSequence, "Expected the last step sequence to be $expectedLastSequence but it is = ${step.sequence}"; }; }; log.info ""; log.info 'Test Step "' + testRunner.runContext.currentStep.name + '" done...'; Regards, Todd