Combine then statements into one step

owncloud · Nov 13, 2018 · 822159c · 822159c
1 parent a3e9554
commit 822159c
Show file tree

Hide file tree

Showing 27 changed files with 424 additions and 241 deletions.
diff --git a/tests/acceptance/features/apiCapabilities/capabilities.feature b/tests/acceptance/features/apiCapabilities/capabilities.feature
@@ -21,7 +21,6 @@ Feature: capabilities
   Scenario: Check that group sharing can be enabled
     Given parameter "shareapi_allow_group_sharing" of app "core" has been set to "no"
     And the capabilities setting of "files_sharing" path "group_sharing" has been confirmed to be ""
-
     When the administrator sets parameter "shareapi_allow_group_sharing" of app "core" to "yes"
     Then the capabilities setting of "files_sharing" path "group_sharing" should be "1"
 

diff --git a/tests/acceptance/features/apiComments/deleteComments.feature b/tests/acceptance/features/apiComments/deleteComments.feature
@@ -69,18 +69,15 @@ Feature: Comments
   Scenario: deleting a folder removes existing comments on the folder
     Given the user has created a folder "/FOLDER_TO_DELETE"
     When the user comments with content "This should be deleted" on folder "/FOLDER_TO_DELETE" using the WebDAV API
-    Then the user should have 1 comments on folder "/FOLDER_TO_DELETE"
-    When the user deletes folder "/FOLDER_TO_DELETE" using the WebDAV API
+    And the user deletes folder "/FOLDER_TO_DELETE" using the WebDAV API
     And the user has created a folder "/FOLDER_TO_DELETE"
     Then the user should have 0 comments on folder "/FOLDER_TO_DELETE"
 
   Scenario: deleting a user does not remove the comment
     Given the user has created a folder "/FOLDER_TO_COMMENT"
     And the user has shared folder "/FOLDER_TO_COMMENT" with user "user1"
     And user "user1" has commented with content "Comment from sharee" on folder "/FOLDER_TO_COMMENT"
-    Then the user should have the following comments on folder "/FOLDER_TO_COMMENT"
-      | user1 | Comment from sharee |
-    And user "user1" has been deleted
+    When the administrator deletes user "user1" using the provisioning API
     Then the user should have 1 comments on folder "/FOLDER_TO_COMMENT"
     And the user should have the following comments on folder "/FOLDER_TO_COMMENT"
       | deleted_users | Comment from sharee |

diff --git a/tests/acceptance/features/apiFavorites/favorites.feature b/tests/acceptance/features/apiFavorites/favorites.feature
@@ -9,9 +9,7 @@ Feature: favorite
   Scenario Outline: Favorite a folder
     Given using <dav_version> DAV path
     When the user favorites element "/FOLDER" using the WebDAV API
-    And the user gets the following properties of folder "/FOLDER" using the WebDAV API
-      | {http://owncloud.org/ns}favorite |
-    Then the single response should contain a property "{http://owncloud.org/ns}favorite" with value "1"
+    Then as the user the folder "/FOLDER" should be favorited
     Examples:
       | dav_version |
       | old         |
@@ -21,9 +19,7 @@ Feature: favorite
     Given using <dav_version> DAV path
     When the user favorites element "/FOLDER" using the WebDAV API
     And the user unfavorites element "/FOLDER" using the WebDAV API
-    And the user gets the following properties of folder "/FOLDER" using the WebDAV API
-      | {http://owncloud.org/ns}favorite |
-    Then the single response should contain a property "{http://owncloud.org/ns}favorite" with value "0"
+    Then as the user the folder "/FOLDER" should not be favorited
     Examples:
       | dav_version |
       | old         |
@@ -33,9 +29,7 @@ Feature: favorite
   Scenario Outline: Favorite a file
     Given using <dav_version> DAV path
     When the user favorites element "/textfile0.txt" using the WebDAV API
-    And the user gets the following properties of file "/textfile0.txt" using the WebDAV API
-      | {http://owncloud.org/ns}favorite |
-    Then the single response should contain a property "{http://owncloud.org/ns}favorite" with value "1"
+    Then as the user the file "/textfile0.txt" should be favorited
     Examples:
       | dav_version |
       | old         |
@@ -46,9 +40,7 @@ Feature: favorite
     Given using <dav_version> DAV path
     When the user favorites element "/textfile0.txt" using the WebDAV API
     And the user unfavorites element "/textfile0.txt" using the WebDAV API
-    And the user gets the following properties of file "/textfile0.txt" using the WebDAV API
-      | {http://owncloud.org/ns}favorite |
-    Then the single response should contain a property "{http://owncloud.org/ns}favorite" with value "0"
+    Then as the user the file "/textfile0.txt" should not be favorited
     Examples:
       | dav_version |
       | old         |
@@ -131,9 +123,7 @@ Feature: favorite
     And the user has moved file "/textfile0.txt" to "/favoriteFile.txt"
     And the user has shared file "/favoriteFile.txt" with user "user1"
     When the user favorites element "/favoriteFile.txt" using the WebDAV API
-    And user "user1" gets the following properties of file "/favoriteFile.txt" using the WebDAV API
-      | {http://owncloud.org/ns}favorite |
-    Then the single response should contain a property "{http://owncloud.org/ns}favorite" with value "0"
+    Then as user "user1" the file "/favoriteFile.txt" should not be favorited
     Examples:
       | dav_version |
       | old         |
@@ -145,9 +135,7 @@ Feature: favorite
     And the user has moved file "/textfile0.txt" to "/favoriteFile.txt"
     And the user has shared file "/favoriteFile.txt" with user "user1"
     When user "user1" favorites element "/favoriteFile.txt" using the WebDAV API
-    And the user gets the following properties of file "/favoriteFile.txt" using the WebDAV API
-      | {http://owncloud.org/ns}favorite |
-    Then the single response should contain a property "{http://owncloud.org/ns}favorite" with value "0"
+    Then as the user the file "/favoriteFile.txt" should not be favorited
     Examples:
       | dav_version |
       | old         |

diff --git a/tests/acceptance/features/apiFederation/federated.feature b/tests/acceptance/features/apiFederation/federated.feature
@@ -55,7 +55,7 @@ Feature: federated
     When user "user1" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/remote_shares/pending"
     Then the OCS status code should be "100"
     And the HTTP status code should be "200"
-    And the share fields of the last share should include
+    And the fields of the last response should include
       | id          | A_NUMBER                                   |
       | remote      | REMOTE                                     |
       | remote_id   | A_NUMBER                                   |
@@ -106,30 +106,26 @@ Feature: federated
     And user "user0" from server "REMOTE" has accepted the last pending share
     And using server "REMOTE"
     When user "user0" uploads file "data/file_to_overwrite.txt" to "/textfile0 (2).txt" using the WebDAV API
-    And using server "LOCAL"
-    Then the content of file "/textfile0.txt" for user "user1" should be "BLABLABLA" plus end-of-line
+    Then the content of file "/textfile0.txt" for user "user1" on server "LOCAL" should be "BLABLABLA" plus end-of-line
 
   Scenario: Overwrite a federated shared file as recipient - remote server shares - local server receives
     Given user "user0" from server "REMOTE" has shared "/textfile0.txt" with user "user1" from server "LOCAL"
     And user "user1" from server "LOCAL" has accepted the last pending share
     When user "user1" uploads file "data/file_to_overwrite.txt" to "/textfile0 (2).txt" using the WebDAV API
-    And using server "REMOTE"
-    Then the content of file "/textfile0.txt" for user "user0" should be "BLABLABLA" plus end-of-line
+    Then the content of file "/textfile0.txt" for user "user0" on server "REMOTE" should be "BLABLABLA" plus end-of-line
 
   Scenario: Overwrite a file in a federated shared folder as recipient - local server shares - remote server receives
     Given user "user1" from server "LOCAL" has shared "/PARENT" with user "user0" from server "REMOTE"
     And user "user0" from server "REMOTE" has accepted the last pending share
     And using server "REMOTE"
     When user "user0" uploads file "data/file_to_overwrite.txt" to "/PARENT (2)/textfile0.txt" using the WebDAV API
-    And using server "LOCAL"
-    Then the content of file "/PARENT/textfile0.txt" for user "user1" should be "BLABLABLA" plus end-of-line
+    Then the content of file "/PARENT/textfile0.txt" for user "user1" on server "LOCAL" should be "BLABLABLA" plus end-of-line
 
   Scenario: Overwrite a file in a federated shared folder as recipient - remote server shares - local server receives
     Given user "user0" from server "REMOTE" has shared "/PARENT" with user "user1" from server "LOCAL"
     And user "user1" from server "LOCAL" has accepted the last pending share
     When user "user1" uploads file "data/file_to_overwrite.txt" to "/PARENT (2)/textfile0.txt" using the WebDAV API
-    And using server "REMOTE"
-    Then the content of file "/PARENT/textfile0.txt" for user "user0" should be "BLABLABLA" plus end-of-line
+    Then the content of file "/PARENT/textfile0.txt" for user "user0" on server "REMOTE" should be "BLABLABLA" plus end-of-line
 
   Scenario: Overwrite a federated shared file as recipient using old chunking
     Given user "user0" from server "REMOTE" has shared "/textfile0.txt" with user "user1" from server "LOCAL"
@@ -139,8 +135,7 @@ Feature: federated
       | 2 | BBBBB |
       | 3 | CCCCC |
     Then the content of file "/textfile0 (2).txt" for user "user1" should be "AAAAABBBBBCCCCC"
-    And using server "REMOTE"
-    Then the content of file "/textfile0.txt" for user "user0" should be "AAAAABBBBBCCCCC"
+    Then the content of file "/textfile0.txt" for user "user0" on server "REMOTE" should be "AAAAABBBBBCCCCC"
 
   Scenario: Overwrite a file in a federated shared folder as recipient using old chunking
     Given user "user0" from server "REMOTE" has shared "/PARENT" with user "user1" from server "LOCAL"
@@ -150,8 +145,7 @@ Feature: federated
       | 2 | BBBBB |
       | 3 | CCCCC |
     Then the content of file "/PARENT (2)/textfile0.txt" for user "user1" should be "AAAAABBBBBCCCCC"
-    And using server "REMOTE"
-    And the content of file "/PARENT/textfile0.txt" for user "user0" should be "AAAAABBBBBCCCCC"
+    And the content of file "/PARENT/textfile0.txt" for user "user0" on server "REMOTE" should be "AAAAABBBBBCCCCC"
 
   Scenario: Trusted server handshake does not require authenticated requests - we force 403 by sending an empty body
     Given using server "LOCAL"
@@ -166,26 +160,23 @@ Feature: federated
     And user "user0" has stored etag of element "/PARENT (2)"
     And using server "LOCAL"
     When user "user1" uploads file "data/file_to_overwrite.txt" to "/PARENT/textfile0.txt" using the WebDAV API
-    Then using server "REMOTE"
-    And the etag of element "/PARENT (2)" of user "user0" should have changed
+    Then the etag of element "/PARENT (2)" of user "user0" on server "REMOTE" should have changed
 
   Scenario: Overwrite a federated shared folder as recipient propagates etag for sharer
     Given user "user1" from server "LOCAL" has shared "/PARENT" with user "user0" from server "REMOTE"
     And user "user1" has stored etag of element "/PARENT"
     And user "user0" from server "REMOTE" has accepted the last pending share
     And using server "REMOTE"
     When user "user0" uploads file "data/file_to_overwrite.txt" to "/PARENT (2)/textfile0.txt" using the WebDAV API
-    Then using server "LOCAL"
-    And the etag of element "/PARENT" of user "user1" should have changed
+    Then the etag of element "/PARENT" of user "user1" on server "LOCAL" should have changed
 
   Scenario: Upload file to received federated share while quota is set on home storage
     Given user "user0" from server "REMOTE" has shared "/PARENT" with user "user1" from server "LOCAL"
     And user "user1" from server "LOCAL" has accepted the last pending share
     And using server "LOCAL"
     When user "user1" uploads file "data/textfile.txt" to "/PARENT (2)/testquota.txt" with all mechanisms using the WebDAV API
     Then the HTTP status code of all upload responses should be "201"
-    And using server "REMOTE"
-    And as "user0" the files uploaded to "/PARENT/testquota.txt" with all mechanisms should exist
+    Then as user "user0" on server "REMOTE" the files uploaded to "/PARENT/testquota.txt" with all mechanisms should exist
 
   Scenario: Upload file to received federated share while quota is set on remote storage - local server shares - remote server receives
     Given using server "LOCAL"

diff --git a/tests/acceptance/features/apiMain/checksums.feature b/tests/acceptance/features/apiMain/checksums.feature
@@ -39,8 +39,7 @@ Feature: checksums
     Given using <dav_version> DAV path
     And user "user0" has uploaded file "data/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a"
     When user "user0" moves file "/myChecksumFile.txt" to "/myMovedChecksumFile.txt" using the WebDAV API
-    And user "user0" requests the checksum of "/myMovedChecksumFile.txt" via propfind
-    Then the webdav checksum should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960"
+    Then as user "user0" the webdav checksum of "/myMovedChecksumFile.txt" via propfind should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960"
     Examples:
       | dav_version |
       | old         |
@@ -99,8 +98,7 @@ Feature: checksums
     Given using new DAV path
     And user "user0" has uploaded file "data/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a"
     When user "user0" copies file "/myChecksumFile.txt" to "/myChecksumFileCopy.txt" using the WebDAV API
-    And user "user0" requests the checksum of "/myChecksumFileCopy.txt" via propfind
-    Then the webdav checksum should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960"
+    Then as user "user0" the webdav checksum of "/myChecksumFileCopy.txt" via propfind should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960"
 
   Scenario: Copying file with checksum should return the checksum in the download header using new DAV path
     Given using new DAV path
@@ -123,8 +121,7 @@ Feature: checksums
     And user "user0" has uploaded file "data/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a"
     When user "user0" shares file "/myChecksumFile.txt" with user "user1" using the sharing API
     And user "user1" uploads file with checksum "SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399" and content "Some Text" to "/myChecksumFile.txt" using the WebDAV API
-    And user "user0" requests the checksum of "/myChecksumFile.txt" via propfind
-    Then the webdav checksum should match "SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399 MD5:56e57920c3c8c727bfe7a5288cdf61c4 ADLER32:1048035a"
+    Then as user "user0" the webdav checksum of "/myChecksumFile.txt" via propfind should match "SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399 MD5:56e57920c3c8c727bfe7a5288cdf61c4 ADLER32:1048035a"
 
   Scenario: Upload new dav chunked file where checksum matches
     Given using new DAV path
@@ -256,8 +253,7 @@ Feature: checksums
   Scenario Outline: Uploading a file with MD5 checksum overwriting an existing file
     Given using <dav_version> DAV path
     When user "user0" uploads file "data/textfile.txt" to "/textfile0.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" using the WebDAV API
-    And user "user0" requests the checksum of "/textfile0.txt" via propfind
-    Then the webdav checksum should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960"
+    Then as user "user0" the webdav checksum of "/textfile0.txt" via propfind should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960"
     And the content of file "/textfile0.txt" for user "user0" should be:
       """
       This is a testfile.
@@ -272,8 +268,7 @@ Feature: checksums
   Scenario Outline: Uploading a file with SHA1 checksum overwriting an existing file
     Given using <dav_version> DAV path
     When user "user0" uploads file "data/textfile.txt" to "/textfile0.txt" with checksum "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f" using the WebDAV API
-    And user "user0" requests the checksum of "/textfile0.txt" via propfind
-    Then the webdav checksum should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960"
+    Then as user "user0" the webdav checksum of "/textfile0.txt" via propfind should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960"
     And the content of file "/textfile0.txt" for user "user0" should be:
       """
       This is a testfile.
@@ -289,8 +284,7 @@ Feature: checksums
   Scenario Outline: Uploading a file with invalid SHA1 checksum overwriting an existing file
     Given using <dav_version> DAV path
     When user "user0" uploads file "data/textfile.txt" to "/textfile0.txt" with checksum "SHA1:f005ba11f005ba11f005ba11f005ba11f005ba11" using the WebDAV API
-    And user "user0" requests the checksum of "/textfile0.txt" via propfind
-    Then the webdav checksum should match "SHA1:0c1d334e686d1039c9ead0dbc047f02dbf696be8 MD5:d991cd854c53729d066c6ed5e34bcda3 ADLER32:8685092b"
+    Then as user "user0" the webdav checksum of "/textfile0.txt" via propfind should match "SHA1:0c1d334e686d1039c9ead0dbc047f02dbf696be8 MD5:d991cd854c53729d066c6ed5e34bcda3 ADLER32:8685092b"
     And the content of file "/textfile0.txt" for user "user0" should be "ownCloud test text file 0" plus end-of-line
     Examples:
       | dav_version |

diff --git a/tests/acceptance/features/apiMain/transfer-ownership.feature b/tests/acceptance/features/apiMain/transfer-ownership.feature
@@ -189,8 +189,8 @@ Feature: transfer-ownership
     And user "user1" has created a public link share with settings
       | path | /test/somefile.txt |
     When the administrator transfers ownership of path "test" from "user0" to "user1" using the occ command
-    And the command should have been successful
-    Then the downloaded content when downloading file "/test/somefile.txt" for user "user2" with range "bytes=0-6" should be "This is"
+    Then the command should have been successful
+    And the downloaded content when downloading file "/test/somefile.txt" for user "user2" with range "bytes=0-6" should be "This is"
 
   @skipOnEncryptionType:user-keys
   Scenario: transferring ownership of folder shared with third user

diff --git a/tests/acceptance/features/apiProvisioning-v1/apiProvisioningUsingAppPassword.feature b/tests/acceptance/features/apiProvisioning-v1/apiProvisioningUsingAppPassword.feature
@@ -36,7 +36,7 @@ Feature: access user provisioning API using app password
   Scenario: normal user gets their own information using the app password
     Given user "newuser" has been created
     And a new client token for "newuser" has been generated
-    Given a new browser session for "newuser" has been started
+    And a new browser session for "newuser" has been started
     And the user has generated a new app password named "my-client"
     When the user requests "/ocs/v1.php/cloud/users/newuser" with "GET" using the generated app password
     Then the HTTP status code should be "200"
@@ -60,7 +60,7 @@ Feature: access user provisioning API using app password
     Given user "newuser" has been created
     And user "anotheruser" has been created
     And a new client token for "newuser" has been generated
-    Given a new browser session for "newuser" has been started
+    And a new browser session for "newuser" has been started
     And the user has generated a new app password named "my-client"
     When the user requests "/ocs/v1.php/cloud/users/anotheruser" with "GET" using the generated app password
     Then the OCS status code should be "997"

diff --git a/tests/acceptance/features/apiProvisioning-v1/enableUser.feature b/tests/acceptance/features/apiProvisioning-v1/enableUser.feature
@@ -60,6 +60,8 @@ Feature: enable user
     And user "subadmin" has been made a subadmin of group "new-group"
     And user "subadmin" has been disabled
     When user "subadmin" sends HTTP method "PUT" to OCS API endpoint "/cloud/users/subadmin/enabled"
+    Then the OCS status code should be "997"
+    And the HTTP status code should be "401"
     And user "subadmin" should be disabled
 
   Scenario: Making a web request with an enabled user

diff --git a/tests/acceptance/features/apiProvisioning-v1/getUsers.feature b/tests/acceptance/features/apiProvisioning-v1/getUsers.feature
@@ -34,6 +34,6 @@ Feature: get users
     Given user "normaluser" has been created
     And user "newuser" has been created
     When user "normaluser" sends HTTP method "GET" to OCS API endpoint "/cloud/users"
-    And the OCS status code should be "997"
+    Then the OCS status code should be "997"
     And the HTTP status code should be "401"
     And the API should not return any data