Showing ideas with status Accepted for Discussion.
Show all ideas
Status:
Accepted for Discussion
Submitted on
07-08-2021
01:17 AM
Submitted by
AAB
on
07-08-2021
01:17 AM
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
See more ideas labeled with:
Status:
Accepted for Discussion
Submitted on
03-20-2021
04:30 AM
Submitted by
f4br3
on
03-20-2021
04:30 AM
Hello, everyone! Given the breakthrough and popularity of Apple's new silicon (M1), I think there should be an optimized version of ReadyAPI for this silicon, as it will obviously run faster than using Rosetta 2. Thanks!
... View more
Status:
Accepted for Discussion
Submitted on
02-17-2021
08:15 AM
Submitted by
baukeplugge
on
02-17-2021
08:15 AM
Hi All, is there an option to create PHP code based on the WDSL function selected in ReadyAPI ?
... View more
Status:
Accepted for Discussion
Submitted on
09-13-2019
02:11 PM
Submitted by
gruve
on
09-13-2019
02:11 PM
It would be convenient to be able to clone an authentication profile, both within and between projects.
... View more
Status:
Accepted for Discussion
Submitted on
08-06-2019
12:04 AM
Submitted by
kkotaramesh
on
08-06-2019
12:04 AM
Hello, Just the way we have integration of Ready API to Zephyr cloud, Can we have the same integration wtih Zephyr Server too ? My organisation uses Zephyr server and we are very eagerly looking for the integration of zephyr with Ready API so that once Ready API project runs, Mapped zephyr test cases gets executed.
Currently i see that we have that in Zephyr cloud and not on zephyr server. Can we have it on Zephyr server too. Thanks.
We have a case 00397737 on the same.
... View more
Status:
Accepted for Discussion
Submitted on
05-31-2019
10:24 AM
Submitted by
thePantz
on
05-31-2019
10:24 AM
I ran into an issue after following this article to place sqljdbc_auth.dll into my <ReadyAPI>/bin to allow for windows authorization on my JDBC requests.
This works great until ReadyAPI updates, this file is not copied over to the new directory e.g. ReadyAPI-2.6.0 to ReadyAPI-2.7.0. The fact that my project depends on this file and I can't included it with the rest of my project files means that there will always be confusion whenever there is an upgrade.
Please either have ReadyAPI automatically copy this .dll to the new directory when there is an update or allow users to maintain this file as part of their project
... View more
Status:
Accepted for Discussion
Submitted on
09-11-2018
05:17 AM
Submitted by
Lucian
on
09-11-2018
05:17 AM

It would be nice to have a way to enable and disable certain headers in requests.
... View more
Status:
Accepted for Discussion
Submitted on
08-10-2017
09:37 PM
Submitted by
kbw
on
08-10-2017
09:37 PM
Enhancement Request: It would be useful if we add an extra "Suite Group", or "Suite Categories" level in the SoapUI test case hierarchy for organizing test suites. This would be a parent of Test Suite. This way you could collapse.expand categories of test suites. This should be an optional level, so that those who just want test suites wouldn't need to have the extra layer of categories. Reasoning for it's usefulness: Currently, in each project, we organize tests by test suite, and test case. There is no broader category than test suite. In a situation where you have multiple APIs that while might mostly be independent, but that do also have interaction with each other, it would be handy to have them all be in a single project. However, if each API itself needs several test suites for testing it, then having multiple APIs in a single project isn't great for organizing your test suites, since they're all in a flat structure at the test suite level. That's one reason for keeping the APIs in different projects, so that you can expand only the test suites for the given API, without seeing a bit list of all the other API's test suites. The most common usage for Suite Groups/Categories would likely be to organize test suites by each API in the project, but their would certainly be other categories that people would come up with.
... View more
Status:
Accepted for Discussion
Submitted on
09-06-2016
11:01 AM
Submitted by
tgeliot
on
09-06-2016
11:01 AM
If I walk up to a workstation that has Ready!API up, I can't readily tell if a test package, suite, case, or step is in the middle of running, let alone which one is running. If something is executing, it should be glaringly obvious on the screen no matter which other item somebody has selected to look at, and it should be easy to tell what is running, and where it is in its sequence. I'm using Ready!API 1.8.0
... View more
Status:
Accepted for Discussion
Submitted on
08-04-2016
08:58 AM
Submitted by
RBlack
on
08-04-2016
08:58 AM
AFAIK for SoapUI versions up to 1.8.0, the calltestcase step only supports calling test cases within the same project. We have hundreds of utility test cases in a large project with ~1000 application level test cases that use them. We also have another project containing tests that need to call the same utility test cases. Currently we have to maintain two copies of the utility test cases because the second project cannot call into the first. Instead, we would like to have one SoapUI project containing the utility test cases, and multiple other projects containing the application level test cases that call into the utility tests. Then we would not need multiple copies of the utility test cases, which is a maintenance headache. So we'd like to request a SoapUI enhancement to support calling test cases in other projects. That would reduce our maintenance efforts considerably.
... View more
Status:
Accepted for Discussion
Submitted on
11-23-2015
06:15 AM
Submitted by
marcl
on
11-23-2015
06:15 AM
We currently have around a dozen composite projects, which all use the same set of API. The reason we use so much projects instead of a single big one is for performance reasons. When an API change (adding a new method, adding a parameter, etc) we thus have to update the API of each of the projects manually. We currently work around that by using symlinks, but this solution is clunky at best. To prevent that, we would like some way to "share" the API definitions between multiple projects, having the API described in a single place and useable by all other projects. The choosen solution should be compatible with version-control systems (e.g. something we can submit / check out), so any employee with a fresh computer can simply check-out the project(s) and start working without any extra configuration.
... View more
Status:
Accepted for Discussion
Submitted on
04-29-2015
09:57 PM
Submitted by
maximojo
on
04-29-2015
09:57 PM
More of an annoying thing, http://screencast.com/t/pJnh4bzuq I had a support issue where my report wasn't coming out as pdf because the case for the passed in format has to be upper case so: PDF Please allow the dialog to handle upper AND lower case.
... View more
Status:
Accepted for Discussion
Submitted on
04-08-2015
02:14 AM
Submitted by
chatelao
on
04-08-2015
02:14 AM
We specify our JSON-Format-Definition with the JSON-Schema. It would be nice to validate the data directly within SOAP-UI. Schema specification (IETF RFC Draft) http://tools.ietf.org/html/draft-fge-json-schema-validation-00 Understanding JSON-Schema: http://spacetelescope.github.io/understanding-json-schema/ Generating JSON-Schemas: http://jsonschema.net/#/ Validating JSON-Schemas: http://json-schema-validator.herokuapp.com/ Using JUnit Tests rest-assured: http://www.jayway.com/2013/12/10/json-schema-validation-with-rest-assured/
... View more