in version 3.9.0 there is a smartAssertion created that deprecates the HTTP assertions. As all of my testcases (a huge amount) have this assertion I'm not going to adapt them manually as this will take a huge effort to do so. No clue why Smartbear has deleted this assertion as I think quasi all of the testers are using this!? Please, re-install the HTTP assertions!
... View more
I get exception when calling def sql = groovyUtilsPro.getGroovySql('<db name>'): java.lang.indexOutOfBoundsException: No group 5 error at line: 5 WORKAROUND: def sql = Sql.newInstance(groovyUtilsPro.getJdbcConnection('<db name>').getMetaData().getURL()) CODE LISTING: import groovy.sql.Sql import com.eviware.soapui.support.GroovyUtilsPro def groovyUtilsPro = new GroovyUtilsPro(context) def sql = groovyUtilsPro.getGroovySql('<db name>') DETAILS: DB is MySql, same works for other Oracle DB configured in the project, so it may be connector bug tried mysql-connector-java-8.0.24 and .23, both produce same exception
... View more
In their current implementation 1.) the TestEngine needs to be provided a zip with all required files by the calling client 2.) the TestEngine Jenkins plugin will execute one Project/Suite/Case per Jenkins job Problem: This setup does not scale to execute many Project/Suite/Case SoapUI tests in a row Suggestion: ad 1.) a.) Provide TestEngine the ability to access/checkout GIT repos containing SoapUI Projects b.) Add an API to TestEngine that will take the Project/Suite/Case/... parameters and pick all required files from above local checkout area --> Like this no files need to be created/transfered to the TestEngine server What still needs to be done is the specification of the list of Project/Suite/Case to be executed. This could be provided by one or more config files maintained in the GIT repo(s) ad 2.) In case the TestEngine runs on the Jenkins slave(s), the Jenkins job could - checkout the GIT repo(s) - locate the config file(s) containing the list of /Project/Suite/Case SoapUI Tests in the checkout area (e.g. via parameter) - loop the config file(s) calling the TestEngine API with Project/Suite/Case/... parameters --> like this - The TestEngine is running as a server (contrary to testruner.sh) - The invocation of many Project/Suite/Case's will run with minimal overhead (presumably msecs instead of secs) - all required files are taken from a repo -> any updates propagate to TestEngine automatically Remark: This type of automated execution of SoapUI Test from different Project/Suite/Case needs to complemented with a suitable test report (e.g. csv file with Project/Suite/Case/Step, timeStamp, Status, ExecTime, ErrorMsg, ...
... View more
Here you can review submitted feature requests and vote up the ones you like! If you can't find the feature you want - go ahead and suggest your own idea. Ideas with the highest rating can be implemented in the product.