Manage the projectVersion field in "Setting.xml" , so it doesn't update with every save or reload
Reference Issue -https://community.smartbear.com/t5/ReadyAPI-Questions/Ready-API-3-42-0-automatically-updates-projectVersion-every-time/m-p/240988/emcs_t/S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufExBSklETVhHWkdEMTUxfDI0MDk4OHxTVUJTQ1JJUFRJT05TfGhL#M57307 projectVersion value changes everytime a project is saved. When trying to Pull changes from git, setting.xml needs to be committed first, but it re-appears again as a new change, which blocks pulling from git. The "Discard all changes", don't really discard the document.
Test different resource values in SOAP UI
Hi, I am trying to create tests for the endpoint which ends like this: /account/id where id can have different values. In SOAP UI I want to test whether the correct value return 200, and other incorrect values return 400, so I would like to have tests: 1. /account/1234 - correct 2. /account/abc - incorrect However I am unable to change the values of the resource in Test Cases in SOAP UI as it is hardcoded: Is there any way I can change resource depending on the test?
ReadyAPI and TestEngine with Zephyr Scale
In this post, we are going to talk about using some of the SmartBear API testing tools and writing the results in an automated fashion to Zephyr Scale. But first let's take a step back and discuss a general approach of using testing tools with test management tools. At a manual level, when creating simple Multi-Protocol API tests, we might use a lighter weight tool like SoapUI Open Source, a great tool for quick and basic functional and performance API tests. After we trigger the test manually, we as humans would parse the report for any details on the test run, and to track it would update a spreadsheet, testcase in Jira, but somewhere. This sequence is important to note for when we start to advance to an automated workflow. Now let's talk about automating this process. We execute our API tests in an ephemeral environment, publish the results to a relative location, and then pass those results from that relative location to a test management platform. It is quite simple. In this workflow it tends to be easier to use a tool that has native integrations into CI platforms like Jenkins and Azure Dev Ops, that make managing our executions in these ephemeral environments much easier. Here, ReadyAPI, or TestEngine is the clear choice as they both seamlessly integrate into any CI-CD system and have native integrations into Jenkins, Azure, and many more. Now that sequence I mentioned earlier is very important. We will execute our API tests, and then pass the results into Zephyr Scale as step 2 in the pipeline. Here is a look at a scripted pipeline approach, note that there is freestyle job options available in Jenkins too. ReadyAPI Jenkins Plugin: https://support.smartbear.com/readyapi/docs/integrations/jenkins.html TestEngine Jenkins Plugin: https://support.smartbear.com/testengine/docs/admin/jenkins.html node { stage('Run API Tests') { // Run the API Tests using ReadyAPI or TestEngine stage('Pass Results') { //Pass Results to Zephyr Scale } } Now we need to be a little more specific with the 'Run API Tests' Stage. Above I mention when we run our API Tests in an automated fashion, we need to write the results to a relative location so that we can then send those results to Zephyr Scale from that location. Both ReadyAPI and TestEngine allow us to write results to locations as part of the command-line or native integrations. I will show command- line options for ReadyAPI and UI native integration for TestEngine but both options are available for both tools. Starting with ReadyAPI, testrunner CLI, the -f and -F flags represent the directory we are writing to, and the report format, respectively. ReadyAPI offers reports in PDF, XLS, HTML, RTF, CSV, TXT and XML, but the automation recommendation would be to pass results in the Junit-XML option. At a basic level we need this: testrunner.bat [optional-arguments] <test-project> And we need to specify -f and -F testrunner.bat -f<directory> -F<args> <test-project> and with -f requiring a relative directory, that can change based on the CI system. I will use Azure Dev Ops for both my examples here. In Azure I pull my test cases from the $(System.DefaultWorkingDirectory), which contains my git repo. In Azure I publish results to the $(Common.TestResultsDirectory) An example full command would look like this: "C:\Program Files\SmartBear\ReadyAPI-3.40.1\bin\testrunner.bat" -r -a -j -f$(Common.TestResultsDirectory) "-RJUnit-Style HTML Report" -FXML "-EDefault environment" "$(System.DefaultWorkingDirectory)/" With TestEngine it's very similar, but I am highlighting it through the native integration, note the publish test results and save Junit report option enabled below: Now lastly, we need to send the results to Zephyr Scale from the pipeline, before our release is over. I think it's easiest with the Zephyr Scale API: https://support.smartbear.com/zephyr-squad-cloud/docs/api/index.html along with the Auto-Create Test Case option to true. The command below is a basic example, and replica of the one seen in the Azure Pipeline screenshot. curl -H "Authorization: Bearer Zephyr-Scale-Token-Here" -F file= Relative-Location-of-Report-Here\report.xml;type=application/xml "https://api.zephyrscale.smartbear.com/v2/automations/executions/junit?projectKey=Project-Key-Here&autoCreateTestCases=true" After you modify the API token, Relative location, and project key you are good to run the pipeline. When we jump to Jira, we can see inside Zephyr Scale that the results are populating. Even with transactional Data on the failed test steps.
Run From Here at the Test Case level (not just the test step level)
I distinctly remember being able to use a 'Run From Here' option (context menu when right clicking a test case from the Test Suite summary screen i.e. the one where the bars show green and red when a test passes or fails). It seems to be gone in one of the last versions? I can see inside a Test case if you right mouse click on a test step you can select run from here. What happens to me is I have a suite with 20 cases and case 14 fails. I then inspect it and want to run case 15 onwards so in the past I would right mouse click this test case and choose Run From Here ...Script library interoperability, javaDoc, refactoring, search & autocomplete in all scripts
I'm sorry, but to me the idea mentioned Intellisense-on-custom-groovy-librarybyrunzTHalmost 6 years ago (wow!) is still not implemented, even though labeled as such. In current version ReadyAPI 3.10.0 I still do not have the kind of intellisense I would like to see: - no hassling with .jar files, I want to have interoperability with all of the groovy files in my custom script library like defined in the ReadyAPI project. A restart of some sort I can understand, but when we need to start with importing files we know this is something that will only work locally and for that version. - PLEASE: Proper IDE capabilities, like auto-complete, auto-formatting, code error detections (missing curly bracket for instance), renaming/refactoring, search (and replace),... in ALL scripts (setup scripts, groovy tests steps, tear downs, script library,...). It is such a breeze when I use other (front-end) test automation tools to see that I can do those things, but then return to ReadyAPI and feel like an IT-guy from the 90's. - I'd like proper javaDoc documentations to know what each method does. Currently I can only see what parameter type(s) I need to provide, but not what this method actually does or what I can expect to be returned. Scripting is such an extra weapon to be used in ReadyAPI, it's a shame it cannot be made more powerful by Smartbear.Add an event for Report post-processing
The need In ReadyAPI there are nice options of reporting, however there is missing any function to do report post-processing. The post-processing needs are: to send a report via email put the report into a storage create a Jira item etc. Currently the report files are just placed in the output directory. On TestCase and TestSuite level there are Report script holders, but the purpose of the script is toextend the reporting options(it is executed before the reports are finished, not after), i.e. for report pre-processing. On the project level there is no such option. Solution proposal A good place to execute specific actions arethe events. But there is no "ReportListener.afterReport" event. Please add a new event ReportListener.afterReport which will be triggered after any report is finished by testrunner. Such event will be used by Groovy scripts to do the report post-processing.Delete multiple selected request headers at once [BUG?]
Current behaviour: 1) In the additional request headers tab of a SOAP/REST test step I select multiple headers (the selected headers visually are selected by having the color blue = OK). 2) I click on the delete bin button. 3) Only the first header is deleted. Expected behaviour: ALL of the selected headers should be deleted. If a use wants to delete 10 headers he now has to manually select them and delete them one-by-one. This is frustrating. Note: this issue has been around for ages. Additionally: We (luckily) can select and copy the headers properly by doing a select and then Ctrl+C. The feature of copy-pasting request headers might not be really visible in the UI (e.g. there is no "copy" button), but I am very grateful this is possible through Ctrl+C. Might be wise to visually allow this to?
