Contributions
Re: Not able to Launch SoapUI
I've never gotten that message before, and I've been using SoapUI for years. I would try 4 things: Disable antivirus software, then try to start SoapUI. Verify that you aren't behind a firewall that would block a JVM (Java Virtual Machine) from running. Do you have Java 7 or up installed on your system? SoapUI just dropped support for Java 6. Run SoapUI as an administrator. Did any of those work?1.1KViews0likes0CommentsRe: [Res]how to add property into header
It should be pretty straightforward; I'm wondering if you've formatted your property expansion correctly. Say I have a TestSuite level property named tokenA that I want to use as the token. So my header setup would look like this, with the property expansion formatted like ${#TestSuite#tokenA}: I think that should work. -E10 years agoPlace ReadyAPI QuestionsReadyAPI Questions2.1KViews0likes0CommentsRe: Best approach for handling URLs without hard coding?
Thanks everyone! I'll give the Groovy script a try. Thanks Jeshtha! I have used property to store my URL and used property expension to call the property from the URL field. So when I change environments I do it within the property only. @smadji: this won't work, as some of the URLs in the response have {parameters} appended to the end of the URL. I described this in my original post but probably not well. Basically the "junk" (i.e. parameters in curly brackets) is also appended to the end of the URL, which makes the resulting property-transferred-endpoint improperly formatted & invalid, which means I get a 400 or 404 error. I was looking for a way to strip out the extra junk at the end so that I had a properly-formatted URL that will work with my test cases.10 years agoPlace ReadyAPI QuestionsReadyAPI Questions4.1KViews0likes0CommentsBest approach for handling URLs without hard coding?
Hi everyone, While I'm a seasoned SoapUI user, I'm new to the Pro version, and thus new to the concept of how environments work within SoapUI Pro. I'm working on a RESTFUL API that uses HATEOAS principles. HATEOAS testing is also new to me. I'm trying to avoid hard-coding URLs into each of my test steps in order to make it easy to run in various dev, staging, and QA environments. Originally my approach was to grab the URL from a response and transfer it to the endpoint of subsequent test steps. It's great when the response looks like this: { "link" : [ { "rel" : "self", "href" : "http://dev.foo.com/web-rest/webapi/authenticated" } but when I have a response that looks like this, with the parameters included: { "rel" : "clients", "href" : "http://dev.foo.com/web-rest/webapi/clients{?page,size,sort,name,status}" } It doesn't work because {?page,size,sort,name,status} is included in the endpoint for subsequent tests. I need to pass just http://dev.foo.com/web-rest/webapi/clients so the request can complete without a 400, 401, or 404. So, how should I handle this? Is this response format common for REST APIs using HATEOAS? Is there a way for me to use the links provided in the responses in subsequent test steps so that I only have to specify the domain/starting endpoint at the beginning of my test runs? Should I ask the developer to change the way the response is laid out so that the possible parameters are not included in the links? Can environments take care of this for me? Halp!!1! Thanks! -E10 years agoPlace ReadyAPI QuestionsReadyAPI Questions4.5KViews0likes3CommentsRe: XPath Match Configuration window Declare button not working
So... what if I need to use a wildcard in my assertions then? Say, for example, I have a test that sends user credentials and the response returns a username. I set the username as a project-level property, which means I can vary the username from test run to test run. I may first choose to run the test with userA, then again with userB. With my understanding of JSON assertions, I'm not sure how to In the past, I used XML assertions to check for the presence of that element (username) without checking for the specific username by using a wildcard for the <username> field, like this: <response> <color>red</color> <username>*</username> </response> SmartBear Support wrote: Hi, I see that you are using a REST webservice, I would suggest you to use Json path since namespaces can be ignored in json. Also I will try to reproduce the issue. Thanks, Jeshtha10 years agoPlace ReadyAPI QuestionsReadyAPI Questions2.6KViews0likes0CommentsRe: XPath Match Configuration window Declare button not working
Yep, that's it. I know when I was using the not-Pro version of SoapUI I'd click that Declare button and it would pre-fill the top box with a pre-formatted declaration with ns1 as the namespace... Or maybe my memory is failing me.10 years agoPlace ReadyAPI QuestionsReadyAPI Questions2.6KViews0likes0CommentsRe: XPath Match Configuration window Declare button not working
I'm not sure I get what you are saying nmrao. The response does not have a declare button... Unless I'm missing something. The declare button is a SoapUI feature in Xpath assertions.10 years agoPlace ReadyAPI QuestionsReadyAPI Questions2.6KViews0likes0CommentsRe: XPath Match Configuration window Declare button not working
The issue lies in the auto-generation of the declaration, not in the response or my ability to view it. When I manually type the correct Xpath selector, and then I click the button to select from the current response, that part works just fine. It's not a big bug, but it does save me some time to automatically generate the declaration and then just update the namespace to whatever I'd like. Here is a sample response if that helps, but I'm finding this is the case across the board for all responses. <public> <links> <link rel="self" href="http://dev.company.com:8080/web-rest/webapi"/> <link rel="authenticated" href="http://dev.company.com:8080/web-rest/webapi/authenticated"/> <link rel="authenticate" href="http://dev.company.com:8080/web-rest/webapi/authenticate"/> <link rel="logout" href="http://dev.company.com:8080/web-rest/webapi/logout"/> </links> </public>10 years agoPlace ReadyAPI QuestionsReadyAPI Questions2.6KViews0likes0CommentsRe: [Registered] XML View Not Coming in REST Service Response
So, what functionality do you feel you are losing by not being able to see the XML representation of the JSON? Can you use wildcards for JSON assertions? This is really useful for responses that come back with timestamps, for example. -E10 years agoPlace ReadyAPI QuestionsReadyAPI Questions7.3KViews0likes0Comments