Schema Name Length from Export Definition
I was wondering if there was any way to control the naming of the schemas when you do an Export Definition. I have a wsdl that has a bunch of operations. When you export it, the schema names become REALLY long. Too long for Visual Studio to handle when adding this wsdl as a service reference. Example: Service_1_2_3_4_5_6_7_8_9_10_11_12_13_14_15_16_17_18_19_20_21_22_23_24_25_26_27_28_29_30_31_32_33_34_35_36_37_38_39_40_41_42_43_44_45_46_47_48_49_50_51_52_53_54_55_56_57_58_59.xsd Is there anyway to control the names given? Can I just manually rename them and change the wsdl?1.4KViews1like2CommentsDefect? - SoapUI Cloning Test Steps duplicates API endpoints
When cloning test steps from one test case to another, it duplicates API endpoints & methods. When I delete the duplicated endpoints/Methods, it deletes the endpoints from the currently used API's but keeps the methods. Using Version 3.7.0.Solved1.2KViews0likes4CommentsAPI call in test | aqHttp | Request Library | Test Complete | External Python Libraries
I want to make a http request but the Test Complete moduleaqHttp does not provide the features I need. Certain feature I am looking for are allow_redirect, verify_certificate, and so on. The python libary requests does have all these feature. I imported this libary in the manner suggestion by the community while double checking I have the same python version install globally as Test Complete (Python 3.6). sys.path.insert(0, 'C:\\Python36\\Lib\\site-packages') import requests def Testing123(): response = requests.get("https://www.example.com", verify=False) if(response.status_code == 200): Log.Message("All is good!") The libary loads and all seems good but when I run the the function a second time all if Test Complete crashes. This kind of unpredictable behavior is constant when using these 3rd party libaries which are nessessary some of the more complicated tests. Does anyone have an tips?Solved1.7KViews0likes5CommentsSoapUI Maven plugin 5.2.1 bug report
We've found that after the SoapUI Maven plugin has run the default ProxySelector in the Java network stack is messed up. Looking at the code it appears that the plugin sets the proxy selector to null (line 186, see e.g. ProxyUtils.java). While not explicitly stated in the JavaDoc, I think it should not be set to null. If SoapUI needs a null value here, it should restore the original proxy selector that was nulled once the plugin finished. With the proxy selector being null, other code running after the plugin fails, e.g. Apache HttpClient 4.5.2 cannot work any more and produces a NullPointerException.1.3KViews1like1CommentSoapUI NG Pro - Empty Expected Result in XPath Match results in passed Assertion
Pre-Condition: - Valid XML Response Steps: 1. Add a "Xpath Match Assertion" 2. Enter a valid Xpath Expression which fits the given reply (click on "select from current test" would return acutal value in Expected Result) 3. Delete any String which is entered in "Expected Result" 4. Run test Expected Result: - Assertion Failed, because given Expression is not empty Acutal Result: - Assertion Passed Tested with 1.5.0 and 1.6.0Solved2KViews0likes3Comments[SoapUI 5.2.1 bug report] Reproducible project corruption on SoapUI exit
Environment:SoapUI 5.2.1 with Java SE 1.8.0_45-b14 on Windows 7 Pro x64. Actual result: I have a project containing two services with both mock up and requests. On SoapUI exit (no matter how it was initiated: menu, shortcut, red X) corrupts the project when clilcking on "Yes", it remains OK when clicking "No". Even after clicking "Yes" it stays open! The corruption is that the contents of request A gets overwritten with the contents of request B. Workaround: Save manually and close SoapUI with "Exit without saving". Expected result: SoapUI closes on "Exit" and does not corrupt the project.853Views0likes0Comments