New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[full-ci][tests-only]Expand tests coverage related to user with different role #5725
Conversation
ac15d3f
to
77e68b2
Compare
e2b57bc
to
9a77eea
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can use username to delete user, so no need to get the user ID.
IMO, not needed for this PR
i asked Viktor which method should we use he told me to use user id to delete the user. So i implemented deletion of user using user-id. If you don't want to implement deletion of the user using UUID in this PR then i can make new PR to add scenario where user delete user by UUID |
^ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use setResponse()
within the When
implementation only.
@saw-jan if we have to setResponse() in When step then we can do that by returning response from function why to remove function which help to implement DRY concept? |
Yeah, my only suggestion is to use |
9a77eea
to
c49edd8
Compare
c49edd8
to
242e2c2
Compare
242e2c2
to
6c22874
Compare
6c22874
to
7325909
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
686ad6a
to
fa6fea6
Compare
fa6fea6
to
9d50ae9
Compare
Kudos, SonarCloud Quality Gate passed! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
…rent role (#5725) * Refactor tests related to different role * Use setResponse from When step
@amrita-shrestha just a reminder that this needs to be backported to stable-2.0 (with skip on stable tag probably?) TODO
|
…rent role (#5725) * Refactor tests related to different role * Use setResponse from When step
…rent role (#5725) * Refactor tests related to different role * Use setResponse from When step
…rent role (#5725) * Refactor tests related to different role * Use setResponse from When step
Description
This PR expand tests coverage related to the user with all role to create, edit, delete, get the user
As Viktor Scharf told
403 Forbidden vs 401 Unauthorized. I would be expect 403 code. But we definitely have chaos here and often for developers - 401 ok. in case non-existent - 404 or 403. looking at witch checking is first.
So scenario like below has check for http status 401
As Artur suggested running the authorization and non-existent related scenarios and adding them to the expected failure file
Related Issue
Motivation and Context
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Checklist: