Improved checks in tests for apiProvisioning-v1 suite

tests/acceptance/features/apiProvisioning-v1/addUser.feature

@@ -155,6 +155,7 @@ Feature: add user
       | 123      |
       | -123     |
       | 0.0      |
+
   @notToImplementOnOCIS
   Scenario: subadmin should not be able to create a new user
     Given user "brand-new-user" has been deleted
@@ -174,6 +175,7 @@ Feature: add user
     Then the OCS status code should be "997"
     And the HTTP status code should be "401"
     And user "brand-new-user" should not exist
+
   @notToImplementOnOCIS
   Scenario: subadmin should be able to create a new user into their group
     Given user "brand-new-user" has been deleted
@@ -185,6 +187,7 @@ Feature: add user
     Then the OCS status code should be "100"
     And the HTTP status code should be "200"
     And user "brand-new-user" should exist
+
   @notToImplementOnOCIS
   Scenario: subadmin should not be able to create a new user into other group
     Given user "brand-new-user" has been deleted

tests/acceptance/features/apiProvisioning-v1/apiProvisioningUsingAppPassword.feature

@@ -31,9 +31,9 @@ Feature: access user provisioning API using app password
     And a new browser session for "brand-new-user" has been started
     And the user has generated a new app password named "my-client"
     When the user requests "/ocs/v1.php/cloud/users" with "GET" using the generated app password
-    Then the users returned by the API should be
+    Then the HTTP status code should be "200"
+    And the users returned by the API should be
       | another-new-user |
-    And the HTTP status code should be "200"
 
   @smokeTest
   Scenario: normal user gets their own information using the app password
@@ -61,8 +61,9 @@ Feature: access user provisioning API using app password
     And a new browser session for "brand-new-user" has been started
     And the user has generated a new app password named "my-client"
     When the user requests "/ocs/v1.php/cloud/users" with "GET" using the generated app password
-    Then the users returned by the API should not include "another-new-user"
-    And the HTTP status code should be "200"
+    Then the HTTP status code should be "200"
+    And the users returned by the API should not include "another-new-user"
+
 
   Scenario: normal user tries to get other user information using the app password
     Given these users have been created with default attributes and without skeleton files:

tests/acceptance/features/apiProvisioning-v1/deleteUser.feature

@@ -72,6 +72,7 @@ Feature: delete users
     Then the OCS status code should be "100"
     And the HTTP status code should be "200"
     And user "another-admin" should not exist
+
   @notToImplementOnOCIS
   Scenario: subadmin deletes a user with subadmin permissions in their group
     Given these users have been created with default attributes and without skeleton files:
@@ -86,6 +87,7 @@ Feature: delete users
     Then the OCS status code should be "100"
     And the HTTP status code should be "200"
     And user "another-subadmin" should not exist
+
   @notToImplementOnOCIS
   Scenario: subadmin should not be able to delete another subadmin of same group
     Given these users have been created with default attributes and without skeleton files:
@@ -99,6 +101,7 @@ Feature: delete users
     Then the OCS status code should be "997"
     And the HTTP status code should be "401"
     And user "another-subadmin" should exist
+
   @notToImplementOnOCIS
   Scenario: subadmin should not be able to delete a user with admin permissions in their group
     Given these users have been created with default attributes and without skeleton files:
@@ -113,6 +116,7 @@ Feature: delete users
     Then the OCS status code should be "997"
     And the HTTP status code should be "401"
     And user "another-admin" should exist
+
   @notToImplementOnOCIS
   Scenario: subadmin should not be able to delete a user not in their group
     Given these users have been created with default attributes and without skeleton files:

tests/acceptance/features/apiProvisioning-v1/enableUser.feature

@@ -64,7 +64,9 @@ Feature: enable user
     And user "another-admin" has been added to group "admin"
     And user "another-admin" has been disabled
     When user "another-admin" tries to enable user "another-admin" using the provisioning API
-    Then user "another-admin" should be disabled
+    Then the OCS status code should be "997"
+    And the HTTP status code should be "401"
+    And user "another-admin" should be disabled
 
   Scenario: normal user tries to enable other user
     Given these users have been created with default attributes and without skeleton files:

tests/acceptance/features/apiProvisioning-v1/getSubAdmins.feature

@@ -13,10 +13,11 @@ Feature: get subadmins
     And group "brand-new-group" has been created
     And user "brand-new-user" has been made a subadmin of group "brand-new-group"
     When the administrator gets all the subadmins of group "brand-new-group" using the provisioning API
-    Then the subadmin users returned by the API should be
-      | brand-new-user |
-    And the OCS status code should be "100"
+    Then the OCS status code should be "100"
     And the HTTP status code should be "200"
+    And the subadmin users returned by the API should be
+      | brand-new-user |
+
 
   Scenario: admin tries to get subadmin users of a group which does not exist
     Given user "brand-new-user" has been created with default attributes and without skeleton files

tests/acceptance/features/apiProvisioning-v1/getUser.feature

@@ -113,56 +113,38 @@ Feature: get user
     And the last login returned by the API should be a current Unix timestamp
 
   @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0
-  Scenario: a normal user gets their own information, providing uppercase username as authentication
+  Scenario Outline: a normal user gets their own information, providing uppercase username as authentication and in the URL
     Given these users have been created with default attributes and without skeleton files:
       | username       | displayname |
       | brand-new-user | New User    |
-    When user "BRAND-NEW-USER" retrieves the information of user "brand-new-user" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And the display name returned by the API should be "New User"
-    And the quota definition returned by the API should be "default"
-    And the free, used, total and relative quota returned by the API should exist and be valid numbers
-    And the last login returned by the API should be a current Unix timestamp
-
-  @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0
-  Scenario: a normal user gets their own information, providing uppercase username in the URL
-    Given these users have been created with default attributes and without skeleton files:
-      | username       | displayname |
-      | brand-new-user | New User    |
-    When user "brand-new-user" retrieves the information of user "BRAND-NEW-USER" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And the display name returned by the API should be "New User"
-    And the quota definition returned by the API should be "default"
-    And the free, used, total and relative quota returned by the API should exist and be valid numbers
-    And the last login returned by the API should be a current Unix timestamp
-
-  @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0
-  Scenario: a mixed-case normal user gets their own information, providing lowercase username in the URL
-    Given these users have been created with default attributes and without skeleton files:
-      | username       | displayname |
-      | Brand-New-User | New User    |
-    When user "Brand-New-User" retrieves the information of user "brand-new-user" using the provisioning API
+    When user "<username1>" retrieves the information of user "<username2>" using the provisioning API
     Then the OCS status code should be "100"
     And the HTTP status code should be "200"
     And the display name returned by the API should be "New User"
     And the quota definition returned by the API should be "default"
     And the free, used, total and relative quota returned by the API should exist and be valid numbers
     And the last login returned by the API should be a current Unix timestamp
+    Examples:
+      | username1      | username2      |
+      | BRAND-NEW-USER | brand-new-user |
+      | brand-new-user | BRAND-NEW-USER |
 
   @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0
-  Scenario: a mixed-case normal user gets their own information, providing the mixed-case username in the URL
+  Scenario Outline: a mixed-case normal user gets their own information, providing lowercase and mixed-case username in the URL
     Given these users have been created with default attributes and without skeleton files:
       | username       | displayname |
       | Brand-New-User | New User    |
-    When user "brand-new-user" retrieves the information of user "Brand-New-User" using the provisioning API
+    When user "<username1>" retrieves the information of user "<username2>" using the provisioning API
     Then the OCS status code should be "100"
     And the HTTP status code should be "200"
     And the display name returned by the API should be "New User"
     And the quota definition returned by the API should be "default"
     And the free, used, total and relative quota returned by the API should exist and be valid numbers
     And the last login returned by the API should be a current Unix timestamp
+    Examples:
+      | username1      | username2      |
+      | Brand-New-User | brand-new-user |
+      | brand-new-user | Brand-New-User |
 
   @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0
   Scenario: admin gets information of a user with admin permissions

tests/acceptance/features/apiProvisioning-v1/getUsers.feature

@@ -35,10 +35,11 @@ Feature: get users
     And user "brand-new-user" has been added to group "brand-new-group"
     And user "brand-new-user" has been made a subadmin of group "brand-new-group"
     When user "brand-new-user" gets the list of all users using the provisioning API
-    Then the users returned by the API should be
-      | brand-new-user |
-    And the OCS status code should be "100"
+    Then the OCS status code should be "100"
     And the HTTP status code should be "200"
+    And the users returned by the API should be
+      | brand-new-user |
+
 
   Scenario: normal user tries to get other users
     Given these users have been created with default attributes and without skeleton files:

tests/acceptance/features/apiProvisioning-v1/resetUserPassword.feature

@@ -152,7 +152,9 @@ Feature: reset user password
       | /remote.php/dav/files/%username%/textfile0.txt     |
     Then the HTTP status code of responses on all endpoints should be "207"
     When user "brand-new-user" resets the password of user "brand-new-user" to "%alt1%" using the provisioning API
-    Then the content of file "textfile0.txt" for user "brand-new-user" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line
+    Then the OCS status code should be "100"
+    And the HTTP status code should be "200"
+    And the content of file "textfile0.txt" for user "brand-new-user" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line
     When the user "brand-new-user" requests these endpoints with "PROPFIND" to get property "d:getetag" using basic auth and generated app password about user "brand-new-user"
       | endpoint                                           |
       | /remote.php/dav/files/%username%/textfile0.txt     |