Closed zoriya closed 1 year ago
Yes, I agree that the behaviour of Set Headers
is a little unintuitive as the scope is set to suite level. However, I don't feel comfortable on replacing the behaviour outright, since some tests and suites "out there" might depend on this behaviour. This heavily relates to #130, so we could probably leave Set Headers
behaviour as is, add an additional scope=test/suite
parameter, or add a new keyword to remove/clear headers, so that you could use as a test setup/teardown to remove certain headers from your requests.
Test suite maps to a single endpoint, which includes different HTTP verbs (as test cases). These verbs most often use the same authentication and other headers. Thus headers can be overridden per method.
Intuition is a subjective thing.
I am not the biggest fan of the keyword either though as its scope is not clear without reading keyword documentation.
I think having. scope
parameter would be the best way to prevent breaking changes and keep tests simple without having more teardowns.
That would probably be easiest in user point-of-view, but unfortunately also the solution that would require probably the most refactoring. Luckily these are not mutually exclusive solutions, so in theory the library could support both options.
Yes that is the way I see it as well.
The scope of the library is test suite, thus all keywords work on the suite level. This may or may not be confusing depending on the case, but it is the simplest we can do.
Also:
Couldn't this be handled by automatically registering a teardown to reset the header when the Set Header
method is called? This way, users do not need to create a teardown step manually and only one request client can be used.
I do not know the API of robot, so I don't know how easy that would be to implement.
This issue is stale because it has been open for 30 days with no activity.
This issue was closed because it has been inactive for 14 days since being marked as stale.
Header created using
Set Header
are not rested for following tests. This cause a weird behavior for tests like this one:The second test succeeds because the http client is still logged in due to the previous test but it should fail.