fsamwel
Occasional Contributor
Joined 6 years ago
User Profile
User Widgets
Contributions
undefined is not an object (evaluating 'm[b]')
I get in Swaggerhub errors "undefined is not an object (evaluating 'm[b]')" that I can't explain. Can you please tell me what could be wrong with the specifications that could cause this? I tested the specs with swagger-cli validate and with npm run oas:lint (https://github.com/stoplightio/spectral) and they don't give any error or warning. Steps to reproduce: 1. Open https://app.swaggerhub.com/apis/VNG-sandbox/Waardering-onroerende-zaken/0.1.0 2. In the right pane click the caret to open component "WozObjectHal" 3. Now the code pane shows 6 errors "undefined is not an object (evaluating 'm[b]')", all at line 0.1.3KViews0likes1CommentRe: Default Off for "Abort test if an error occurs?"
Hi nmrao, Thanks for your support. What I do is mostly test GET requests from an already filled database. So there are no setup steps or something like that. The same would apply to any test of other operations that would not require a second step to validate (like check validation on POST requests). That means that one request is one testcase, and one testcase is one request (using testcase in ISTQB or TMap terms, not necessarily in ReadyApi terms). What I thus do is use the testcases (in ReadyApi) to bundle related teststeps/testcases.Otherwise there is no use for having testcases, and checking teststep failure would add another step every time (open the case first and then open the request to see what failed). For example one ReadyApi project would have a test scenario for each operation (like "GET /pet", "GET /store" and "GET /user") and one test case for each feature (testcases like "parameter validation", "authenticate", "filter with fields", "eager loading with expand"). And then each test case would contain several teststeps. So before submitting a feature request I first wanted to make sure I've not missed a setting somewhere.2.4KViews0likes4CommentsRe: Default Off for "Abort test if an error occurs?"
the answer you link to explains how to change this setting for every testcase. What I would like, is to set the default testcase configuration, so I don't have to manually change this setting for every testcase I make. Is there a way to do that? I would expect something like that because: 1. the out of the box default makes no sense in testing RESTful API's 2. when adding a new testcase in several ways (like from a operation-request or duplicating an existing request (F9) into a new testcase) only the testcase name is asked, and the testcase is created with these default settings. I didn't find such setting in Preferences, but perhaps there is a way using some Global Properties or other way to change that?2.5KViews0likes7CommentsDefault Off for "Abort test if an error occurs?"
Default any new testcase will have option "Abort test if an error occurs?" checked. This means that if a teststep fails any next teststep in that case will not be executed. This makes a lot of sense in some cases, for example if one step does a post to add something and the next step does a get to check it, and the third step does a delete. Or when you're testing a non-REST API where first step would log in and second step would do something that needs sessions data. But many tests would have independent requests. After all, REST API's are stateless, and most methods are idempotent. Test cases then, just like scenarios, are just a way to logically group related requests (e.g. by operation, by quality aspect, by feature). Is there a way to set the default value for "Abort test if an error occurs?" to off/unchecked rather than on/checked for new testcases?Solved2.7KViews0likes9CommentsAPI key security not imported from Swagger (OAS3) yaml
I've imported an open API specifications version 3.0 yaml file at creating a new project. This Swagger OAS definition contains security: security: - apiKeyBAG: [] and in the #/components/securitySchemes: securitySchemes: apiKeyBAG: type: apiKey name: X-Api-Key in: header In ReadyApi SoapUI I don't find this header anywhere and haven't found a way to add this in the Auth Manager. This means I have to manually add this header to every operation in the API. Is there something wrong with the way this was defined in the Swagger file? (I wouldn't think so, SwaggerHub does recognize the security) Or is there another way to get and use the defined security (api key)?Solved1.9KViews1like2CommentsRe: Quotes added in expected result for json
I've added two screenshots. In my json response (Outline) I rightclick the mouse on an attribute and select Add Assertion > for Content. Next the assertion is shown with quotes added to the attribute content. When clicking Select From Current also the attribute content is added surrounded with double quotes. I also noticed that when the attribute is not a string, but for example a boolean, the quotes are not added. regards, Frank3.4KViews0likes2CommentsQuotes added in expected result for json
When taking the actual value to the Expected Result of a JSONPath Match assertion, SoapUI adds double quotes. For example if response is: { "name": "John Doe" } Then when the JSONPatch expression = $.name, clicking Select From Current will add "John Doe" (including the double quotes) to the expected Result box. Next clicking Test wil show the assertion failed. Thus I need to manually remove the quotes to make the assertion correct. Same thing happens when creating the assertion from the response window using Add assertion>for content. Am I doing anything wrong? Is there a setting to change this? N.B. The open source version of SoapUI does this better as it fills the expected result without the quotes. Pro (I'm using SoapUI Pro 2.8.0) should be better than the freeware version, shouldn't it?Solved3.6KViews0likes6Comments