Headers are kept between tests

[zoriya]

Header created using Set Header are not rested for following tests. This cause a weird behavior for tests like this one:

*** Test Cases ***
Login
    Login      username
    [...]

Me cant be accessed without an account
    Get        /auth/me
    Output
    Integer    response status    403

The second test succeeds because the http client is still logged in due to the previous test but it should fail.

[asimell]

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.

[asyrjasalo]

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.

[zoriya]

I think having. scope parameter would be the best way to prevent breaking changes and keep tests simple without having more teardowns.

[asimell]

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.

[asyrjasalo]

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:

• The context should not be up to the user to handle (like otherwise great HttpLibrary assumes), as the issues can always be tackled by arranging test cases to different suites.
• I would not prefer the idea of having several clients either (RequestLibrary) as that does not introduce value with REST APIs.

[zoriya]

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.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.