[tests-only][full-ci]added then steps for apiMain suite

[sushmita56]

Description

This PR adds Then steps to existing API test scenarios to better check the results of When steps.

Suite Covered

• apiMain

Related Issues

• Part of Improve Then steps in API acceptance tests #39512

How Has This Been Tested?

• Locally
• CI

Types of changes

• New feature (non-breaking change which adds functionality)
• Database schema changes (next release will require increase of minor version instead of patch)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:
• Changelog item, see TEMPLATE

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[CLAassistant]

All committers have signed the CLA.

[ownclouders]

💥 Acceptance tests pipeline webUIUpload-chrome-mariadb10.2-php7.4 failed. The build has been cancelled.

https://drone.owncloud.com/owncloud/core/34682/151/1

[sushmita56]

Is there any alternative that we can use instead of repeating When and Then steps again and again?

[saw-jan]

LGTM

[phil-davis]

why do we expect a 409 with "spaces" access?

[kiranparajuli589]

seems like an issue in ocis, the scenario is also not in the expected failures list

[phil-davis]

@kiranparajuli589 maybe we don't even run these features in oCIS??? Please check.

[kiranparajuli589]

this should be running in ocis, but the bug was covered imo, the checksum matches but status is not expected

[kiranparajuli589]

checking it here further owncloud/ocis#3199

[kiranparajuli589]

see the test passing here, https://drone.owncloud.com/owncloud/ocis/9489/23/6
@sushmita56 please use the same status code as it should be in this scenario and later add the failing test to the expected to failures list with linking to the proper issue (may not be registered yet).

[phil-davis]

Is there any alternative that we can use instead of repeating When and Then steps again and again?

We should discuss this. For example:

  Scenario Outline: Copying file with checksum should return the checksum in the download header using new DAV path
    Given using <dav_version> DAV path
    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a"
    When user "Alice" copies file "/myChecksumFile.txt" to "/myChecksumFileCopy.txt" using the WebDAV API
    Then the HTTP status code should be "201"
    When user "Alice" downloads file "/myChecksumFileCopy.txt" using the WebDAV API
    Then the HTTP status code should be "200"
    And the header checksum should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f"
    Examples:
      | dav_version |
      | new         |

The scenario actually wants to test that the checksum is correct when a copy of the file is downloaded. We could change the first When step(s) into Given:

  Scenario Outline: Copying file with checksum should return the checksum in the download header using new DAV path
    Given using <dav_version> DAV path
    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a"
    And user "Alice" has copied file "/myChecksumFile.txt" to "/myChecksumFileCopy.txt"
    When user "Alice" downloads file "/myChecksumFileCopy.txt" using the WebDAV API
    Then the HTTP status code should be "200"
    And the header checksum should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f"
    Examples:
      | dav_version |
      | new         |

The Given step for user "Alice" has copied file... would check the status itself, like we do in other Given steps.

But in this scenario, we are really trying to test that after a file is copied, the checksum is still correct. So the "copy" step is really the action step for the scenario. So we could do:

  Scenario Outline: Copying file with checksum should return the checksum in the download header using new DAV path
    Given using <dav_version> DAV path
    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a"
    When user "Alice" copies file "/myChecksumFile.txt" to "/myChecksumFileCopy.txt" using the WebDAV API
    Then the HTTP status code should be "201"
    And the header checksum when downloading file "/myChecksumFileCopy.txt" using the WebDAV API should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f"
    Examples:
      | dav_version |
      | new         |

We could write a longer Then step he header checksum when downloading file... - we have done that kind of thing in other places. The step would internally download the file, check the HTTP status, and check the checksum.

[sushmita56]

What can we do in such scenarios? @phil-davis @kiranparajuli589

  @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321
  Scenario: Upload new DAV chunked file where checksum matches
    Given using new DAV path
    When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API
    Then the HTTP status code should be "201"
    When user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API
    Then the HTTP status code should be "201"
    When user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API
    Then the HTTP status code should be "201"
    When user "Alice" moves new chunk file with id "chunking-42" to "/myChunkedFile.txt" with checksum "SHA1:5d84d61b03fdacf813640f5242d309721e0629b1" using the WebDAV API
    Then the HTTP status code should be "201"

  Scenario Outline: Sharing and modifying a file should return correct checksum in the propfind using new DAV path
    Given the administrator has set the default folder for received shares to "Shares"
    And auto-accept shares has been disabled
    And using <dav_version> DAV path
    And user "Brian" has been created with default attributes and without skeleton files
    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a"
    When user "Alice" shares file "/myChecksumFile.txt" with user "Brian" using the sharing API
    Then the HTTP status code should be "200"
    When user "Brian" accepts share "/myChecksumFile.txt" offered by user "Alice" using the sharing API
    Then the HTTP status code should be "200"
    When user "Brian" uploads file with checksum "SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399" and content "Some Text" to "/Shares/myChecksumFile.txt" using the WebDAV API
    Then the HTTP status code should be "<response_status>"
    And as user "Alice" the webdav checksum of "/myChecksumFile.txt" via propfind should match "<checksum>"

[kiranparajuli589]

  @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321
  Scenario: Upload new DAV chunked file where checksum matches
    Given using new DAV path
    When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API
    Then the HTTP status code should be "201"
    When user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API
    Then the HTTP status code should be "201"
    When user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API
    Then the HTTP status code should be "201"
    When user "Alice" moves new chunk file with id "chunking-42" to "/myChunkedFile.txt" with checksum "SHA1:5d84d61b03fdacf813640f5242d309721e0629b1" using the WebDAV API
    Then the HTTP status code should be "201"

What can we do in such a scenario? @phil-davis @kiranparajuli589

• introducing an example table for such repeated steps can reduce the number involving when steps but again there will be 3 when steps for this single scenario.
• first when can be switched to given IMO because it involves creating
• if we don't feel like moving to Given and still have no. of when then what to do 🤔 @phil-davis if we have multiple whens then there can be multiple Thens beneath every when step.

[phil-davis]

When user "Alice" does a chunking upload with id "chunking-42" to file "/myChunkedFile.txt" with checksum "SHA1:5d84d61b03fdacf813640f5242d309721e0629b1" and the following chunks using the WebDAV API
  | part | data  |
  | 2     | BBBBB |
  | 3     | CCCCC |
Then the HTTP status of all the chunking upload requests should be "201"

The When step can remember the status of each request - the request that creates id "chunking-42", each request that uploads a chunk, and the final request that moves the "chunking-42" parts to "myChunkedFile.txt"

The Then step can check each request. Probably it can fail immediately that it detects a wrong status - if an early request goes wrong, then the status of the later requests is not really interesting, they are also going to fail.

A lot of the detailed chunking-upload tests could be refactored like that.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[kiranparajuli589]

lgtm 👍

[phil-davis]

That is strange that the first attempt to move chunkinf-42 to myChunkedFile.txt gives a 202 response - the response indicates that it worked, but actually it should not work. We should make an issue and bug-demo scenario about that - I will raise an issue.