Refer to JSON payload in multipart/form-data
I need to test an endpoint accepting multipart/form-data. The endpoint expects a required part with content id "messageToSend" and optional parts with content id's "document[1-x]". The documents are to be file attachments and I want to send the "messageToSend" as a JSON payload. The attachments are working without issue, but using the query parameter value to input my JSON is not great UX. Ideally I would be able to refer to the body below from the query param so the content id is set correctly. You can imagine if the JSON content were much larger it would be painful to use the query parameter as the text box. As you can see in the screenshots above, the JSON payload has the correct Content-Type but no Content-Disposition. Functionally the two parts need to be merged. I either need to be able to: Refer to the JSON from the query parameter where placeholder "REFER_TO_JSON_BODY" (similar to file:fileName). Set the "content id" in the large text box with the rest of the JSON. Kind regards
Set Authorization Method defaults in Auth Manager which can be inherited by environments
Each of my Ready API projects have dozens of tests and 10+ environments each. The authorization methods for each API request/test is the same across all environments, but any time I need to make changes, or add new requests/tests, I have to open up the environment configuration window. and then for each environment I have to: select the api > Edit > Authorization > Configure > Auth Manager > expand out all of the requests/test steps > make any changes (which is like 3 mouse clicks each plus some scrolling) > close > save And then repeat the exact same steps 10+ more times. Even using inheritance within an environment as much as I can, it's incredibly tedious, and often leads to developers making quick one-off changes in the request/test itself which gets applied inconsistently across environments and then wonder why our automated tests start failing I propose being able to use Auth Manager in the "No Environment" to set the authorization methods in one place, which can then be applied to all environments (unless overridden). Basically, in addition to Inherit From Parent, there could be an Inherit From Default Environment. That way, if an environment will be using all the defaults I only need to touch the environment level auth manager once, set Inherit From Default Environment at the project level for each environment, and then apply that to all dependencies. Any time changes need to be made, I could open up the No Environment Auth Manager, make my changes there, and know it will apply to all all environments inheriting from the default.Add a Regular Expression pattern to a String Generator
Current state Currently, the String generator allows to specify the length of the string and the string contents by character categories: Letters – By default, this check box is selected. Digits – By default, this check box is selected. Spaces – By default, this check box is selected. Punctuation marks – By default, this check box is selected. The docs are here https://support.smartbear.com/readyapi/docs/testing/data-driven/types/generator/string.html . Proposal However, there are cases which need more precise string format. Regular expression would allow an elegant way to define the format. I suggest to add an option to set a regular expression pattern. The String generator would follow the regex pattern instead of string length and the above mentioned character categories.Randomly generated values in requests and other ReadyAPI functions
Current situation ReadyAPI DataGenerator provides different random values (random integer, email, name, city, etc.) I like this function since it creates nice test data. However, the random values are only accessible via DataGenerator DataSource. Proposal It would be great if we could use them in: REST, SOAP, and other requests Variable setup Groovy scripts etc. In ReadyAPI the random values could be available via: expansion e.g. ${#Random#FirstName} Get data function adding a Random category in the top level Implementation proposal Wrapping Java Faker (https://github.com/DiUS/java-faker ) would do the task. Java faker can be configured to use localized data (e.g. english names, spanish names, etc.) The faker provides a lot of interesting data useful for testing, just to name few of them: Address Animal App Artist Avatar Aviation Book Business Company Color File Finance Food Name Nation Number PhoneNumber and many more, including some funny categories like ChuckNorris.Folder Structure | Needed asap!
rorySB We as a big company need a folderstructure feature. We need to logical group testsuites! Our existing Testframework (Playwright) with Typescript Code is built like this: So we have API Auth. Tests Ressource Userstories (Testsuite) Mapping Sheet Tests (Testsuite) Failure Retests (Testsuite) Ressource Userstories (Testsuite) Mapping Sheet Tests (Testsuite) Failure Retests (Testsuite) Ressource Userstories (Testsuite) Mapping Sheet Tests (Testsuite) Failure Retests (Testsuite) This structure we cannot create with ReadyAPI We need this feature asap because otherwise it could be messy without folders. So pls pack this feat request in your next sprint! Best regards Kranael
Smart assertion - Allow updating the Smart Assertion without loosing what is already configured
For the Smart Assertion tool to be useful, it must be possible to update current values without losing what is already configured. Currently if a piece of data changes, you have to reload the whole response, which causes the loss of all the previous configuration. Moreover, this makes cloning completely useless because if we clone a test, the configured Smart Assertion doesn't work anymore. You need to reload everything. When you have a lot of elements in your JSON response, and you assert the values against a data source, it's a lot of wasting time redoing what you have already done previously.
Allow for direct comparison of expected and request response within ReadyAPI
Rather than relying on outside tools like jsoneditoronline, having the ability to compare expected response from current response would be very beneficial. A user must take the time to copy the expected and the current responses into jsoneditoronline to understand the differences when we have responses that are quite large. Add a new button to the JSONPath Match Assertion dialog to allow for direct comparison in the tool. (side by side view)
