sevenhill/QSfera
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[full-ci][tests-only]Expand tests coverage related to user with different role (#5725)

Browse Source 
* Refactor tests related to different role

* Use setResponse from When step
This commit is contained in:
Amrita
2023-03-21 10:03:51 +05:45
committed by GitHub
parent 7ed88edc57
commit 71011fc4aa
7 changed files with 291 additions and 52 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tests/acceptance/features/apiGraph/createUser.feature
+3 -2
View File
@@ -8,7 +8,7 @@ Feature: create user
Background:
Given user "Alice" has been created with default attributes and without skeleton files
@issue-3516
Scenario Outline: the admin creates a user
Given the administrator has given "Alice" the role "Admin" using the settings api
When the user "Alice" creates a new user using GraphAPI with the following settings:
@@ -56,8 +56,9 @@ Feature: create user
| role |
| Space Admin |
| User |
| Guest |
@issue-3516
Scenario: a user cannot be created with the name of the disabled user
Given user "Brian" has been created with default attributes and without skeleton files
And the administrator has given "Alice" the role "Admin" using the settings api
tests/acceptance/features/apiGraph/deleteUser.feature
+72 -12
View File
@@ -46,6 +46,7 @@ Feature: delete user
| Admin |
| Space Admin |
| User |
| Guest |
Scenario: the admin user tries to delete his/her own account
@@ -55,22 +56,56 @@ Feature: delete user
And user "Alice" should exist
Scenario: the admin user tries to delete a non-existent user
Given the administrator has given "Alice" the role "Admin" using the settings api
When the user "Alice" deletes a user "nonExistentUser" using the Graph API
Then the HTTP status code should be "404"
Scenario Outline: Non-admin user tries to delete another user with different role
Given user "Brian" has been created with default attributes and without skeleton files
And the administrator has given "Alice" the role "<role>" using the settings api
When the user "Alice" deletes a user "Brian" using the Graph API
Scenario Outline: Non-admin user tries to delete his/her own account
Given the administrator has given "Alice" the role "<role>" using the settings api
When the user "Alice" deletes a user "Alice" using the Graph API
Then the HTTP status code should be "401"
And user "Brian" should exist
And user "Alice" should exist
Examples:
| role |
| Space Admin |
| User |
| Guest |
Scenario: the admin user tries to delete a nonexistent user
Given the administrator has given "Alice" the role "Admin" using the settings api
When the user "Alice" tries to delete a nonexistent user using the Graph API
Then the HTTP status code should be "404"
Scenario Outline: Non-admin user tries to delete a nonexistent user
Given the administrator has given "Alice" the role "<role>" using the settings api
When the user "Alice" tries to delete a nonexistent user using the Graph API
Then the HTTP status code should be "401"
Examples:
| role |
| Space Admin |
| User |
| Guest |
Scenario Outline: Non-admin user tries to delete another user with different role
Given user "Brian" has been created with default attributes and without skeleton files
And the administrator has given "Brian" the role "<role>" using the settings api
And the administrator has given "Alice" the role "<userRole>" using the settings api
When the user "Alice" deletes a user "Brian" using the Graph API
Then the HTTP status code should be "401"
And user "Brian" should exist
Examples:
| userRole | role |
| Space Admin | Space Admin |
| Space Admin | User |
| Space Admin | Guest |
| Space Admin | Admin |
| User | Space Admin |
| User | User |
| User | Guest |
| User | Admin |
| Guest | Space Admin |
| Guest | User |
| Guest | Guest |
| Guest | Admin |
Scenario: the admin user deletes a disabled user
@@ -80,4 +115,29 @@ Feature: delete user
When the user "Alice" deletes a user "Brian" using the Graph API
Then the HTTP status code should be "204"
And user "Brian" should not exist
Scenario Outline: normal user tries to delete a disabled user
Given the administrator has given "Alice" the role "Admin" using the settings api
And user "Brian" has been created with default attributes and without skeleton files
And user "Carol" has been created with default attributes and without skeleton files
And the administrator has given "Brian" the role "<role>" using the settings api
And the administrator has given "Carol" the role "<userRole>" using the settings api
And the user "Alice" has disabled user "Brian" using the Graph API
When the user "Carol" deletes a user "Brian" using the Graph API
Then the HTTP status code should be "401"
And user "Brian" should exist
Examples:
| userRole | role |
| Space Admin | Space Admin |
| Space Admin | User |
| Space Admin | Guest |
| Space Admin | Admin |
| User | Space Admin |
| User | User |
| User | Guest |
| User | Admin |
| Guest | Space Admin |
| Guest | User |
| Guest | Guest |
| Guest | Admin |
tests/acceptance/features/apiGraph/editUser.feature
+47 -12
View File
@@ -83,24 +83,36 @@ Feature: edit user
| role |
| Space Admin |
| User |
| Guest |
Scenario Outline: a normal user should not be able to edit another user's email
Given the administrator has given "Brian" the role "<role>" using the settings api
Given the administrator has given "Brian" the role "<userRole>" using the settings api
And the user "Alice" has created a new user using the Graph API with the following settings:
| userName | Carol |
| displayName | Carol King |
| email | carol@example.com |
| password | 1234 |
And the administrator has given "Carol" the role "<role>" using the settings api
When the user "Brian" tries to change the email of user "Carol" to "newemail@example.com" using the Graph API
Then the HTTP status code should be "401"
And the user "Carol" should have information with these key and value pairs:
| key | value |
| mail | carol@example.com |
Examples:
| role |
| Space Admin |
| User |
| userRole | role |
| Space Admin | Space Admin |
| Space Admin | User |
| Space Admin | Guest |
| Space Admin | Admin |
| User | Space Admin |
| User | User |
| User | Guest |
| User | Admin |
| Guest | Space Admin |
| Guest | User |
| Guest | Guest |
| Guest | Admin |
Scenario Outline: the admin user can edit another user display name
@@ -128,24 +140,36 @@ Feature: edit user
| role |
| Space Admin |
| User |
| Guest |
Scenario Outline: a normal user should not be able to edit another user's display name
Given the administrator has given "Brian" the role "<role>" using the settings api
Given the administrator has given "Brian" the role "<userRole>" using the settings api
And the user "Alice" has created a new user using the Graph API with the following settings:
| userName | Carol |
| displayName | Carol King |
| email | carol@example.com |
| password | 1234 |
And the administrator has given "Carol" the role "<role>" using the settings api
When the user "Brian" tries to change the display name of user "Carol" to "Alice Hansen" using the Graph API
Then the HTTP status code should be "401"
And the user "Carol" should have information with these key and value pairs:
| key | value |
| displayName | Carol King |
Examples:
| role |
| Space Admin |
| User |
| userRole | role |
| Space Admin | Space Admin |
| Space Admin | User |
| Space Admin | Guest |
| Space Admin | Admin |
| User | Space Admin |
| User | User |
| User | Guest |
| User | Admin |
| Guest | Space Admin |
| Guest | User |
| Guest | Guest |
| Guest | Admin |
Scenario: the admin user resets password of another user
@@ -156,21 +180,32 @@ Feature: edit user
Scenario Outline: a normal user should not be able to reset the password of another user
Given the administrator has given "Brian" the role "<role>" using the settings api
Given the administrator has given "Brian" the role "<userRole>" using the settings api
And the user "Alice" has created a new user using the Graph API with the following settings:
| userName | Carol |
| displayName | Carol King |
| email | carol@example.com |
| password | 1234 |
And the administrator has given "Carol" the role "<role>" using the settings api
And user "Carol" has uploaded file with content "test file for reset password" to "/resetpassword.txt"
When the user "Brian" resets the password of user "Carol" to "newpassword" using the Graph API
Then the HTTP status code should be "401"
And the content of file "resetpassword.txt" for user "Carol" using password "1234" should be "test file for reset password"
But user "Carol" using password "newpassword" should not be able to download file "resetpassword.txt"
Examples:
| role |
| Space Admin |
| User |
| userRole | role |
| Space Admin | Space Admin |
| Space Admin | User |
| Space Admin | Guest |
| Space Admin | Admin |
| User | Space Admin |
| User | User |
| User | Guest |
| User | Admin |
| Guest | Space Admin |
| Guest | User |
| Guest | Guest |
| Guest | Admin |
Scenario: the admin user disables another user
tests/acceptance/features/apiGraph/getUser.feature
+81 -22
View File
@@ -9,24 +9,41 @@ Feature: get users
| username |
| Alice |
| Brian |
And the administrator has given "Alice" the role "Admin" using the settings api
Scenario: admin user gets the information of a user
Given the administrator has given "Alice" the role "Admin" using the settings api
When user "Alice" gets information of user "Brian" using Graph API
Then the HTTP status code should be "200"
And the user retrieve API response should contain the following information:
| displayName | id | mail | onPremisesSamAccountName | accountEnabled |
| Brian Murphy | %uuid_v4% | brian@example.org | Brian | true |
Scenario: non-admin user tries to get the information of a user
@issue-5125
Scenario Outline: non-admin user tries to get the information of a user
Given the administrator has given "Alice" the role "<role>" using the settings api
And the administrator has given "Brian" the role "<userRole>" using the settings api
When user "Brian" tries to get information of user "Alice" using Graph API
Then the HTTP status code should be "401"
And the last response should be an unauthorized response
Examples:
| userRole | role |
| Space Admin | Space Admin |
| Space Admin | User |
| Space Admin | Guest |
| Space Admin | Admin |
| User | Space Admin |
| User | User |
| User | Guest |
| User | Admin |
| Guest | Space Admin |
| Guest | User |
| Guest | Guest |
| Guest | Admin |
Scenario: admin user gets all users
Given the administrator has given "Alice" the role "Admin" using the settings api
When user "Alice" gets all users using the Graph API
Then the HTTP status code should be "200"
And the API response should contain following users with the information:
@@ -36,7 +53,8 @@ Feature: get users
Scenario: admin user gets all users include disabled users
Given the user "Alice" has disabled user "Brian" using the Graph API
Given the administrator has given "Alice" the role "Admin" using the settings api
And the user "Alice" has disabled user "Brian" using the Graph API
When user "Alice" gets all users using the Graph API
Then the HTTP status code should be "200"
And the API response should contain following users with the information:
@@ -45,13 +63,20 @@ Feature: get users
| Brian Murphy | %uuid_v4% | brian@example.org | Brian | false |
Scenario: non-admin user tries to get all users
Scenario Outline: non-admin user tries to get all users
Given the administrator has given "Alice" the role "<userRole>" using the settings api
When user "Brian" tries to get all users using the Graph API
Then the HTTP status code should be "401"
And the last response should be an unauthorized response
Examples:
| userRole |
| Space Admin |
| User |
| Guest |
Scenario: admin user gets the drive information of a user
Given the administrator has given "Alice" the role "Admin" using the settings api
When the user "Alice" gets user "Brian" along with his drive information using Graph API
Then the HTTP status code should be "200"
And the user retrieve API response should contain the following information:
@@ -69,7 +94,8 @@ Feature: get users
| webUrl | %base_url%/f/%space_id% |
Scenario: normal user gets his/her own drive information
Scenario Outline: non-admin user gets his/her own drive information
Given the administrator has given "Brian" the role "<userRole>" using the settings api
When the user "Brian" gets his drive information using Graph API
Then the HTTP status code should be "200"
And the user retrieve API response should contain the following information:
@@ -85,10 +111,15 @@ Feature: get users
| root@@@id | %space_id% |
| root@@@webDavUrl | %base_url%/dav/spaces/%space_id% |
| webUrl | %base_url%/f/%space_id% |
Examples:
| userRole |
| Space Admin |
| User |
| Guest |
Scenario: admin user gets the group information of a user
Given group "tea-lover" has been created
Given the administrator has given "Alice" the role "Admin" using the settings api
And group "tea-lover" has been created
And group "coffee-lover" has been created
And user "Brian" has been added to group "tea-lover"
And user "Brian" has been added to group "coffee-lover"
@@ -98,18 +129,34 @@ Feature: get users
| displayName | id | mail | onPremisesSamAccountName | accountEnabled | memberOf |
| Brian Murphy | %uuid_v4% | brian@example.org | Brian | true | tea-lover, coffee-lover |
Scenario: non-admin user tries to get the group information of a user
Given user "Carol" has been created with default attributes and without skeleton files
@issue-5125
Scenario Outline: non-admin user tries to get the group information of a user
Given the administrator has given "Alice" the role "<userRole>" using the settings api
And the administrator has given "Brian" the role "<role>" using the settings api
And group "coffee-lover" has been created
And user "Brian" has been added to group "coffee-lover"
When the user "Carol" gets user "Brian" along with his group information using Graph API
When the user "Alice" gets user "Brian" along with his group information using Graph API
Then the HTTP status code should be "401"
And the last response should be an unauthorized response
Examples:
| userRole | role |
| Space Admin | Space Admin |
| Space Admin | User |
| Space Admin | Guest |
| Space Admin | Admin |
| User | Space Admin |
| User | User |
| User | Guest |
| User | Admin |
| Guest | Space Admin |
| Guest | User |
| Guest | Guest |
| Guest | Admin |
Scenario: admin user gets all users of certain groups
Given user "Carol" has been created with default attributes and without skeleton files
Given the administrator has given "Alice" the role "Admin" using the settings api
And user "Carol" has been created with default attributes and without skeleton files
And the user "Alice" has disabled user "Carol" using the Graph API
And group "tea-lover" has been created
And group "coffee-lover" has been created
@@ -137,7 +184,8 @@ Feature: get users
@skipOnStable2.0
Scenario: admin user gets all users of certain groups
Given user "Carol" has been created with default attributes and without skeleton files
Given the administrator has given "Alice" the role "Admin" using the settings api
And user "Carol" has been created with default attributes and without skeleton files
And group "tea-lover" has been created
And group "coffee-lover" has been created
And group "wine-lover" has been created
@@ -156,7 +204,8 @@ Feature: get users
Scenario Outline: non admin user tries to get users of certain groups
Given the administrator has given "Brian" the role "<role>" using the settings api
Given the administrator has given "Alice" the role "Admin" using the settings api
And the administrator has given "Brian" the role "<role>" using the settings api
And group "tea-lover" has been created
And user "Alice" has been added to group "tea-lover"
When the user "Brian" gets all users of the group "tea-lover" using the Graph API
@@ -170,7 +219,8 @@ Feature: get users
Scenario: admin user gets all users with certain roles and members of a certain group
Given user "Carol" has been created with default attributes and without skeleton files
Given the administrator has given "Alice" the role "Admin" using the settings api
And user "Carol" has been created with default attributes and without skeleton files
And the administrator has given "Brian" the role "Space Admin" using the settings api
And the administrator has given "Carol" the role "Space Admin" using the settings api
And group "tea-lover" has been created
@@ -195,12 +245,21 @@ Feature: get users
Scenario Outline: non-admin user tries to get users with a certain role
Given the administrator has given "Brian" the role "<role>" using the settings api
When the user "Brian" gets all users with role "Admin" using the Graph API
Given the administrator has given "Alice" the role "<userRole>" using the settings api
When the user "Alice" gets all users with role "<role>" using the Graph API
Then the HTTP status code should be "401"
And the last response should be an unauthorized response
Examples:
| role |
| Space Admin |
| User |
| Guest |
| userRole | role |
| Space Admin | Space Admin |
| Space Admin | User |
| Space Admin | Guest |
| Space Admin | Admin |
| User | Space Admin |
| User | User |
| User | Guest |
| User | Admin |
| Guest | Space Admin |
| Guest | User |
| Guest | Guest |
| Guest | Admin |