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

refactored feature files

Browse Source
This commit is contained in:
prajwol
2023-06-08 14:59:03 +05:45
parent b6b85baceb
commit edc8e96469
21 changed files with 236 additions and 191 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tests/acceptance/features/coreApiVersions/fileVersions.feature
+33 -31
View File
@@ -1,6 +1,8 @@
@api
Feature: dav-versions
As a user
I want the versions of files to be available
So that I can manage the changes made to the files
Background:
Given using OCS API version "2"
@@ -8,13 +10,13 @@ Feature: dav-versions
And user "Alice" has been created with default attributes and without skeleton files
Scenario: Upload file and no version is available
Scenario: upload file and no version is available
When user "Alice" uploads file "filesForUpload/davtest.txt" to "/davtest.txt" using the WebDAV API
Then the HTTP status code should be "201"
And the version folder of file "/davtest.txt" for user "Alice" should contain "0" elements
Scenario: Upload file and no version is available using various chunking methods (except new chunking)
Scenario: upload file and no version is available using various chunking methods (except new chunking)
When user "Alice" uploads file "filesForUpload/davtest.txt" to filenames based on "/davtest.txt" with all mechanisms except new chunking using the WebDAV API
Then the HTTP status code should be "200"
And the version folder of file "/davtest.txt-olddav-regular" for user "Alice" should contain "0" elements
@@ -22,7 +24,7 @@ Feature: dav-versions
And the version folder of file "/davtest.txt-olddav-oldchunking" for user "Alice" should contain "0" elements
@smokeTest
Scenario: Upload a file twice and versions are available
Scenario: upload a file twice and versions are available
When user "Alice" uploads file "filesForUpload/davtest.txt" to "/davtest.txt" using the WebDAV API
And user "Alice" uploads file "filesForUpload/davtest.txt" to "/davtest.txt" using the WebDAV API
Then the HTTP status code of responses on each endpoint should be "201, 204" respectively
@@ -30,7 +32,7 @@ Feature: dav-versions
And the content length of file "/davtest.txt" with version index "1" for user "Alice" in versions folder should be "8"
Scenario: Upload a file twice and versions are available using various chunking methods (except new chunking)
Scenario: upload a file twice and versions are available using various chunking methods (except new chunking)
When user "Alice" uploads file "filesForUpload/davtest.txt" to filenames based on "/davtest.txt" with all mechanisms except new chunking using the WebDAV API
And user "Alice" uploads file "filesForUpload/davtest.txt" to filenames based on "/davtest.txt" with all mechanisms except new chunking using the WebDAV API
Then the HTTP status code of responses on all endpoints should be "200"
@@ -39,7 +41,7 @@ Feature: dav-versions
And the version folder of file "/davtest.txt-olddav-oldchunking" for user "Alice" should contain "1" element
@smokeTest
Scenario: Remove a file
Scenario: remove a file
Given user "Alice" has uploaded file "filesForUpload/davtest.txt" to "/davtest.txt"
And user "Alice" has uploaded file "filesForUpload/davtest.txt" to "/davtest.txt"
And the version folder of file "/davtest.txt" for user "Alice" should contain "1" element
@@ -49,7 +51,7 @@ Feature: dav-versions
And the version folder of file "/davtest.txt" for user "Alice" should contain "0" elements
@smokeTest
Scenario: Restore a file and check, if the content is now in the current file
Scenario: restore a file and check its content
Given user "Alice" has uploaded file with content "Test Content." to "/davtest.txt"
And user "Alice" has uploaded file with content "Content Test Updated." to "/davtest.txt"
And the version folder of file "/davtest.txt" for user "Alice" should contain "1" element
@@ -58,7 +60,7 @@ Feature: dav-versions
And the content of file "/davtest.txt" for user "Alice" should be "Test Content."
@smokeTest @skipOnStorage:ceph @skipOnStorage:scality
Scenario: Restore a file back to bigger content and check, if the content is now in the current file
Scenario: restore a file back to bigger content and check its content
Given user "Alice" has uploaded file with content "Back To The Future." to "/davtest.txt"
And user "Alice" has uploaded file with content "Update Content." to "/davtest.txt"
And the version folder of file "/davtest.txt" for user "Alice" should contain "1" element
@@ -67,7 +69,7 @@ Feature: dav-versions
And the content of file "/davtest.txt" for user "Alice" should be "Back To The Future."
@smokeTest @skipOnStorage:ceph
Scenario Outline: Uploading a chunked file does create the correct version that can be restored
Scenario Outline: uploading a chunked file does create the correct version that can be restored
Given using <dav-path> DAV path
And user "Alice" has uploaded file with content "textfile0" to "textfile0.txt"
When user "Alice" uploads file "filesForUpload/davtest.txt" to "/textfile0.txt" in 2 chunks using the WebDAV API
@@ -83,7 +85,7 @@ Feature: dav-versions
| old | 201 |
@skipOnStorage:ceph @skipOnStorage:scality
Scenario: Restore a file and check, if the content and correct checksum is now in the current file
Scenario: restore a file and check the content and checksum
Given user "Alice" has uploaded file with content "AAAAABBBBBCCCCC" and checksum "MD5:45a72715acdd5019c5be30bdbb75233e" to "/davtest.txt"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/davtest.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a"
And the version folder of file "/davtest.txt" for user "Alice" should contain "1" element
@@ -93,7 +95,7 @@ Feature: dav-versions
And as user "Alice" the webdav checksum of "/davtest.txt" via propfind should match "SHA1:acfa6b1565f9710d4d497c6035d5c069bd35a8e8 MD5:45a72715acdd5019c5be30bdbb75233e ADLER32:1ecd03df"
Scenario: User cannot access meta folder of a file which is owned by somebody else
Scenario: user cannot access meta folder of a file which is owned by somebody else
Given user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "123" to "/davtest.txt"
And we save it into "FILEID"
@@ -101,13 +103,13 @@ Feature: dav-versions
Then the HTTP status code should be "400" or "404"
Scenario: User cannot access meta folder of a file which does not exist
Scenario: user cannot access meta folder of a file which does not exist
Given user "Brian" has been created with default attributes and without skeleton files
When user "Brian" sends HTTP method "PROPFIND" to URL "/remote.php/dav/meta/MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU2OjhjY2QyNzUxLTkwYTQtNDBmMi1iOWYzLTYxZWRmODQ0MjFmNA=="
Then the HTTP status code should be "400" or "404"
Scenario Outline: User cannot access meta folder of a file with invalid fileid
Scenario Outline: user cannot access meta folder of a file with invalid fileid
Given user "Brian" has been created with default attributes and without skeleton files
When user "Brian" sends HTTP method "PROPFIND" to URL "/remote.php/dav/meta/<file-id>/v"
Then the HTTP status code should be "400" or "404"
@@ -119,7 +121,7 @@ Feature: dav-versions
| MTI4NGQyMzgtYWE5Mi00MmNlLWJkxzQtMGIwMDAwMDA5MTU2OjhjY2QyNzUxLTkwYTQtNDBmMi1iOWYzLTYxZWRmODQ0MjFmNA== | 1284d238-aa92-42ce-bd�4-0b0000009156:8ccd2751-90a4-40f2-b9f3-61edf84421f4 | with : and � sign |
Scenario: the version history is preserved when a file is renamed
Scenario: version history is preserved when a file is renamed
Given user "Alice" has uploaded file with content "old content" to "/textfile.txt"
And user "Alice" has uploaded file with content "new content" to "/textfile.txt"
And user "Alice" has moved file "/textfile.txt" to "/renamedfile.txt"
@@ -128,7 +130,7 @@ Feature: dav-versions
And the content of file "/renamedfile.txt" for user "Alice" should be "old content"
Scenario: User can access version number after moving a file
Scenario: user can access version number after moving a file
Given user "Alice" has created folder "testFolder"
And user "Alice" has uploaded file with content "uploaded content" to "textfile0.txt"
And user "Alice" has uploaded file with content "version 1" to "textfile0.txt"
@@ -140,14 +142,14 @@ Feature: dav-versions
And the number of versions should be "3"
Scenario: Original file has version number 0
Scenario: original file has version number 0
Given user "Alice" has uploaded file with content "uploaded content" to "textfile0.txt"
When user "Alice" gets the number of versions of file "textfile0.txt"
Then the HTTP status code should be "207"
And the number of versions should be "0"
Scenario: the number of etag elements in response changes according to version of the file
Scenario: number of etag elements in response changes according to version of the file
Given user "Alice" has uploaded file with content "uploaded content" to "textfile0.txt"
And user "Alice" has uploaded file with content "version 1" to "textfile0.txt"
And user "Alice" has uploaded file with content "version 2" to "textfile0.txt"
@@ -194,20 +196,20 @@ Feature: dav-versions
And the downloaded content should be "uploaded content"
Scenario: User can retrieve meta information of a root folder
Scenario: user can retrieve meta information of a root folder
When user "Alice" retrieves the meta information of file "/" using the meta API
Then the HTTP status code should be "207"
And the single response should contain a property "oc:meta-path-for-user" with value "/"
Scenario: User can retrieve meta information of a file
Scenario: user can retrieve meta information of a file
Given user "Alice" has uploaded file with content "123" to "/davtest.txt"
When user "Alice" retrieves the meta information of file "/davtest.txt" using the meta API
Then the HTTP status code should be "207"
And the single response should contain a property "oc:meta-path-for-user" with value "/davtest.txt"
Scenario: User can retrieve meta information of a file inside folder
Scenario: user can retrieve meta information of a file inside folder
Given user "Alice" has created folder "testFolder"
And user "Alice" has uploaded file with content "123" to "/testFolder/davtest.txt"
When user "Alice" retrieves the meta information of file "/testFolder/davtest.txt" using the meta API
@@ -215,7 +217,7 @@ Feature: dav-versions
And the single response should contain a property "oc:meta-path-for-user" with value "/testFolder/davtest.txt"
Scenario: User cannot retrieve meta information of a file which is owned by somebody else
Scenario: user cannot retrieve meta information of a file which is owned by somebody else
Given user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "123" to "/davtest.txt "
And we save it into "FILEID"
@@ -223,7 +225,7 @@ Feature: dav-versions
Then the HTTP status code should be "404"
Scenario Outline: User cannot retrieve meta information of a file that does not exist
Scenario Outline: user cannot retrieve meta information of a file that does not exist
When user "Alice" retrieves the meta information of fileId "<file-id>" using the meta API
Then the HTTP status code should be "400" or "404"
Examples:
@@ -234,7 +236,7 @@ Feature: dav-versions
| MTI4NGQyMzgtYWE5Mi00MmNlLWJkxzQtMGIwMDAwMDA5MTU2OjhjY2QyNzUxLTkwYTQtNDBmMi1iOWYzLTYxZWRmODQ0MjFmNA== | 1284d238-aa92-42ce-bd�4-0b0000009156:8ccd2751-90a4-40f2-b9f3-61edf84421f4 | with : and � sign |
Scenario: File versions sets back after getting deleted and restored from trashbin
Scenario: file versions sets back after getting deleted and restored from trashbin
Given user "Alice" has uploaded file with content "Old Test Content." to "/davtest.txt"
And user "Alice" has uploaded file with content "New Test Content." to "/davtest.txt"
And the version folder of file "/davtest.txt" for user "Alice" should contain "1" element
@@ -250,14 +252,14 @@ Feature: dav-versions
And the content of file "/davtest.txt" for user "Alice" should be "Old Test Content."
Scenario: Upload the same file twice with the same mtime and a version is available
Scenario: upload the same file twice with the same mtime and a version is available
Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the WebDAV API
When user "Alice" uploads file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the WebDAV API
Then the HTTP status code should be "204"
And the version folder of file "/file.txt" for user "Alice" should contain "1" element
Scenario: Upload the same file more than twice with the same mtime and only one version is available
Scenario: upload the same file more than twice with the same mtime and only one version is available
Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the WebDAV API
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the WebDAV API
When user "Alice" uploads file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the WebDAV API
@@ -265,7 +267,7 @@ Feature: dav-versions
And the version folder of file "/file.txt" for user "Alice" should contain "1" element
Scenario: Upload the same file twice with the same mtime and no version after restoring
Scenario: upload the same file twice with the same mtime and no version after restoring
Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the WebDAV API
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the WebDAV API
When user "Alice" restores version index "1" of file "/file.txt" using the WebDAV API
@@ -369,7 +371,7 @@ Feature: dav-versions
And the content of file "/Shares/sharingfolder/sharefile.txt" for user "Carol" should be "First content"
Scenario Outline: Moving a file (with versions) into a shared folder as the sharee and as the sharer
Scenario Outline: moving a file (with versions) into a shared folder as the sharee and as the sharer
Given using <dav_version> DAV path
And user "Brian" has been created with default attributes and without skeleton files
And user "Brian" has created folder "/testshare"
@@ -394,7 +396,7 @@ Feature: dav-versions
| new | Brian | /testshare |
Scenario Outline: Moving a file (with versions) out of a shared folder as the sharee and as the sharer
Scenario Outline: moving a file (with versions) out of a shared folder as the sharee and as the sharer
Given using <dav_version> DAV path
And user "Brian" has been created with default attributes and without skeleton files
And user "Brian" has created folder "/testshare"
@@ -419,7 +421,7 @@ Feature: dav-versions
| new | Brian | /testshare |
Scenario: Receiver tries to get file versions of unshared file from the sharer
Scenario: receiver tries to get file versions of unshared file from the sharer
Given user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "textfile0" to "textfile0.txt"
And user "Alice" has uploaded file with content "textfile1" to "textfile1.txt"
@@ -430,7 +432,7 @@ Feature: dav-versions
And the value of the item "//s:exception" in the response about user "Alice" should be "Sabre\DAV\Exception\NotFound"
@skipOnStorage:ceph
Scenario: Receiver tries get file versions of shared file from the sharer
Scenario: receiver tries get file versions of shared file from the sharer
Given user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "textfile0" to "textfile0.txt"
And user "Alice" has uploaded file with content "version 1" to "textfile0.txt"
@@ -442,7 +444,7 @@ Feature: dav-versions
Then the HTTP status code should be "403"
Scenario: Receiver tries get file versions of shared file before receiving it
Scenario: receiver tries get file versions of shared file before receiving it
Given user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "textfile0" to "textfile0.txt"
And user "Alice" has uploaded file with content "version 1" to "textfile0.txt"