Get 'name is not defined' error while exporting pyr script to runnable script

[amittendulkar]

Here are the steps to reproduce (OS: Window 7. But I believe this should reproduce on all platforms).

Define a series of post requests with the first one having name="myreq" parameter.

Make sure that any of the subsequent request is making use of some parameter from the myreq (e.g. using myreq.json()['ParentTag']['ChildTag'] in the request data parameter).

Now select all and right click to select Requester -> Export to runnable script.

Notice that you get undefined variable myreq error while the script is being exported.

NOTE: I used s = requests.Session() first and called s.post() for all requests

[kylebebak]

This is tricky to implement.

According to this, variables can't be reliably persisted between tests using unittest.TestCase. Basically, as stated in answers and comments, "Unit tests should be independent".

This is because TestCase doesn't make guarantees about the order in which tests are executed (apparently they're executed alphabetically, but relying on that seems too hacky to me).

In other words, even if I change the export function to check for usage of the name argument and parse it correctly, the tests in the resulting test script won't pass.

I could try to assign the response of a request to a class property of the TestCase, so other requests can reference it, but there's no guarantee the tests run in the order they're defined in the Requester file. This means the response might not be visible to other tests in the TestCase.

Any ideas?

[amittendulkar]

Maybe ask the user to push the named argument requests to ENV block IFF he wants to reference the named object in any other requests. The above request is a prerequisite step anyway and not exactly a separate test case in that sense.

The ENV block can get the named argument variable defined while parsing the named argument request.

Other tests outside the ENV block having named argument won't expose their respective objects to the TestCase class (as they are atomic). We can document it as a limitation.

[kylebebak]

Hey, it's been a while. Sorry for not responding until now.

I'd be happy to review a PR if you want to try to implement this, but I'm not going to work on it myself for the time being.

[amittendulkar]

Thanks for commenting. I might not take up this item in the near future too as I have gone ahead with Robot Framework in combination with the Python Requests package for my specific requirement. Please close/tag it with a comment indicating that it is a low priority item. Any interested person can always reopen it to implement.

[kylebebak]

That sounds like a good way of handling this for now. Thanks!