Forum Discussion
I updated to version 3.10.1 and I still have the same problem. It's very difficult to work with that.
I'm thinking of using another software.
It happens when:
- I rename an assertion
- I change the contents of an assertion
- I clone an assertion
Example of the problem.
There is no message in the log. Except that everything is saved. But it's not.
Not sure, but I think it happens after a test run.
if we open Ready API and change assertions, it will work. But after we run the tests, the save is not working good. (but not every time)
I have to investigate.
Hello cadesnoy65
Yep. That is strange problem. Not one I can reproduce. I can only suggest a work around and see if that helps...
Instead of having assertions on the api invoke test step, maybe have the assertions in a groovy test step. Is the issue only related to assertions in one api invoke test step for one test case or assertions in any api test step in all test cases?
I prefer assertions in a groovy test step so they are not buried deep in the api invoke test step that I have to crack open each assertion to see what it is evaluating. I like to see all the assertions in code at one time.
This issue does not seem to be wide spread (at least others are not reporting it) so that leads me to believe something is specific to your situation. Is it a big project or one that has been modified a lot by different people with different versions of ReadyAPI? Maybe save it back to a monolithic xml project and then back to a composite project to see if it heals. I don't have an answer.
Regards,
Todd
- TNeuschwanger3 years agoChampion Level 1
Hello cadesnoy65
Above you wrote "I'm thinking of using another software." That seem less desirable (very expensive considering you have a large project with lots of time and effort put into it to just abandon) than trying to fix this.
Above you wrote "I can't change everything to use assertions in groovy instead of the assertions features". Can you change just one test case to use groovy asserts where you are having this issue? You don't have to change all the assertions to groovy in the project at once. Try just the one test case and see if it works. I don't know how many assertions you have for that test case that has the issue, but converting over to groovy for it shouldn't take more than ten minutes for every 20 assertions. After you do it once, every other one is a lot faster.
Above you wrote "I can't also switch from composite project to normal project.". I asked if you could change from composite to normal (save as normal) and then back to composite. It does not have to remain as a normal monolithic xml file project. I have done that work flow process in the past and it healed the composite project for me by aligning all the xml pointers that may have become corrupted. Saving from composite to normal and then back to composite is just a few mouse clicks. What is the reason that you can't do that?
Finally, if you think it is a bug, you can report the issue formally to the ReadyAPI Support team - you can do this here:
https://support.smartbear.com/readyapi/message/
I don't know if ReadyAPI support team monitors this community forum, so going directly to the source of help could be your best bet for resolution.
Regards,
Todd
- sonya_m3 years agoSmartBear Alumni (Retired)
- cadesnoy653 years agoOccasional Contributor
Not really,
we have a big project. I can't change everything to use assertions in groovy instead of the assertions features.
I can't also switch from composite project to normal project.
But I appreciated the responses.
Related Content
- 2 years ago