ByronJ
Occasional Contributor
Joined 11 years ago
User Profile
User Widgets
Contributions
[Potential Bug] -J command line argument not acting as expected
Hi all, I have been working with the XML JUnit Reports generated by the testrunner.sh script in Jenkins and am puzzled by the outcome I receive. I make use of an excel spreadsheet that populates various properties through a particular test case run. My expectation is that if there is an error that occurs during a particular iteration of the testcase I would see all properties that were passed to that test case that failed, including those from the spreadsheet. However when I run '-jJ' I get the following: <testcase name="Test" time="3.693"> <properties/> <failure> ###Redacted### </failure> </testcase> Any answer that helps me better represent my datasources' properties will be greatly appreciated! [ On a side note, there is a definite bug in terms of how the command line communicates how the -J command works. To quote the code: Sets the output to include JUnit XML reports adding test properties to the report This is however, not true. It does not turn on exporting JUnit XML reports. It only adds the properties object. It would be cool if this could be fixed as only specifying one arg would be nice and clean :D ] Kind regards,Ready!API Licensing and Jenkins
Hi all, I have been working at length on the QA strategy for my company and have in the past licensed a single key against a static AWS EC2 instance. I wanted to ask here so that there is a clearly communicated answer, if it is ok for me to license and unlicense that 1 key against an ephemeral docker container? As that container will only live for 1 run of the test pack, the license itself will constantly be installed and then uninstalled. I am not wanting to breach any contractual agreements, so I am interested to find out an answer. Just to be clear: Only 1 instance of the license will be registered at any given time. Thank you for any feedback. It is most welcome!Re: Update definition problem
Hi, Ludo15101966, There are two things I feel are worth mentioning: 1) If at all possible I would advise that you stress to the development team that they rather provide you with a WADL. While ready!api is great at dealing with swagger annotation there are certain aspects that it does not pick up well (I think my last usage was against 1.9.0 - I just pulled in a swagger file to keep myself honest). One of the immediate things I noticed was incorrect data typing even though they were expressed in the swagger file. The other was what you have mentioned above with updating. WADL works like a dream and it feels like ready!api parses and displays it better. The only difference that I noticed where swagger was better was that of the info tooltip annotations which are imported beautifully into ready!api. This is wonderful but not a deal breaker. "name" : "redacted", "in" : "query", "description" : "redacted", "required" : false, "type" : "boolean" Another big difference I note between WADL and Swagger that leads me to enforce it as our companies RESTful definition is it's adherence to the folder structure. The Swagger definition file does not nest itself. All nested values are all displayed as from root. Which makes it less intuitive to traverse. 2) The updating functionality can sometimes struggle to course correct itself when dealing with certain schema changes. My suggestion is for you to open up the refactor definition tab and see if all the lines are correctly lined up and that neither of the sides are red. Hope this helps you through this problem.Re: How to disable useless information in diff comparison?
I am a long time supporter of Smartbear and the SoapUi/Ready!API suite and have personally been the reason for a massive uptake in making use of the licensed product. While this problem is manageable with methods that have been stated above, it results in an extraordinary amount of effort to ensure that there are no faulty or unnecessary updates. In the scenario where I am making valid changes to _specific_ tests this is affecting and touching every other element. Meaning a small update results in a big commit that obfuscates the thing that is being updated. This is further highlighted as I find our test packs maturing and growing *looks at one example in source tree - 55 Changes*. I cannot stress how important it is that this issue is focused on and adjusted for composite projects. Composite project 1.4 anyone? +1 for Improvement (P.S. I can't wait for 1.10.0 or 2.0.0 ;D)
