TNeuschwanger
Champion Level 3User Profile
Champion Level 3
User Widgets
Contributions
Re: Upgrade Best Practices?
Hello scot1967 I don't know if I should stay in my lane or not, but my only Smartbear tool use is ReadyAPI and it looks like the discussion is based around TestComplete. All of the above/below suggestions seem spot on. I will just comment on my experience with ReadyAPI... Since I/we (the team I work with) have never been bit by an upgrade bite (yet), when new versions are released, we upgrade. Maybe just because we don't want to answer daily nag screen that annoys until upgraded :). We have developed a simple batch file to invoke that loads our common libraries to the install location of new version and away we go. Download to restart in working condition is about five minutes down time. This is for our local usage... Only after a period of time (months) do we upgrade the CI/CD machine however (unless new feature usage is mandated). We might have a different usage scenario for ReadyAPI also... We are highly dependent on the scripting capability within ReadyAPI which is a little more protected from change than the product itself. Because of that usage of scripts, we use ReadyAPI not only for our bread and butter API testing, but also user interface testing of Web, Mobile and Windows Desktop applications via ReadyAPI integration with Playwright and Selenium, Appium and Winium. That allows for no context switching to achieve a test case in any paradigm.34Views1like0CommentsRe: ReadyApi 3.64.0 parallel execution
Hello DLeidelmeijer I do not have a solution for you since there could me many things contributing to what you see, especially when you mention it is often groovy... You might want to review the library changes to 3.64.0 which includes many updates to groovy libraries ( https://support.smartbear.com/readyapi/docs/en/what-s-new/version-history/libraries-updated-in-readyapi-3-64-0.html#libraries-updated-in-readyapi-3-64-0 ) to see if your groovy code invokes any of them. If your groovy code is not thread tolerant, that could be a contributor to the abnormal behavior seen when running parallel. just some thoughts... regards57Views0likes0CommentsRe: Tab view instead of many open windows
I agree this would be a big help for SoapUI. However, consider that Smartbear is a for-profit company. :) Their actual paid for product ReadyAPI has that feature. If it matters to you enough for that feature you could pay up for it. I literally hold my breath each day hoping Smartbear does not abandon SoapUI. I think that would be terrible for many reasons, but maybe the wrong person gets in their executive department and decides it is not worth the upkeep. I can tolerate the annoyance to use a free product that does so many other things well. :)57Views0likes0CommentsExpand 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.18Views0likes0CommentsRe: 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.57Views0likes0CommentsRe: 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, Todd49Views0likes0CommentsRe: 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, Todd35Views0likes0CommentsRe: 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, Todd68Views1like0CommentsRe: 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}"; };215Views2likes1CommentRe: 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, Todd31Views0likes0Comments
Groups
Community Champions
21 Posts
