Refactor acceptance test scenarios with public WebDAV API checks

[phil-davis]

We have test scenarios like:

  Scenario Outline: Trying to create a new public link share of a file with edit permissions only grants read access using the public WebDAV API
    Given using OCS API version "<ocs_api_version>"
    And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt"
    When user "Alice" creates a public link share using the sharing API with settings
      | path        | randomfile.txt |
      | permissions | all            |
    Then the OCS status code should be "<ocs_status_code>"
    And the HTTP status code should be "200"
    And the fields of the last response to user "Alice" should include
      | item_type              | file            |
      | mimetype               | text/plain      |
      | file_target            | /randomfile.txt |
      | path                   | /randomfile.txt |
      | permissions            | read            |
      | share_type             | public_link     |
      | displayname_file_owner | %displayname%   |
      | displayname_owner      | %displayname%   |
      | uid_file_owner         | %username%      |
      | uid_owner              | %username%      |
      | name                   |                 |
    And the public should be able to download the last publicly shared file using the <public-webdav-api-version> public WebDAV API without a password and the content should be "Random data"
    And the public upload to the last publicly shared file using the <public-webdav-api-version> public WebDAV API should fail with HTTP status code "403"

    @notToImplementOnOCIS @issue-ocis-2079
    Examples:
      | ocs_api_version | ocs_status_code | public-webdav-api-version |
      | 1               | 100             | old                       |
      | 2               | 200             | old                       |

    Examples:
      | ocs_api_version | ocs_status_code | public-webdav-api-version |
      | 1               | 100             | new                       |
      | 2               | 200             | new                       |

The examples for "old" public-webdav-api-version are skipped on oCIS because that "old" API is not implemented on oCIS.

In oC10 all 4 scenario outline examples run. That is rather unnecessary - the Given and When steps are exactly the same for both examples that have the same ocs_api_version. It is only some Then step(s) that are different. On oC10 we could write it like:

  Scenario Outline: Trying to create a new public link share of a file with edit permissions only grants read access using the public WebDAV API
    Given using OCS API version "<ocs_api_version>"
    And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt"
    When user "Alice" creates a public link share using the sharing API with settings
      | path        | randomfile.txt |
      | permissions | all            |
    Then the OCS status code should be "<ocs_status_code>"
    And the HTTP status code should be "200"
    And the fields of the last response to user "Alice" should include
      | item_type              | file            |
      | mimetype               | text/plain      |
      | file_target            | /randomfile.txt |
      | path                   | /randomfile.txt |
      | permissions            | read            |
      | share_type             | public_link     |
      | displayname_file_owner | %displayname%   |
      | displayname_owner      | %displayname%   |
      | uid_file_owner         | %username%      |
      | uid_owner              | %username%      |
      | name                   |                 |
    And the public should be able to download the last publicly shared file using the old public WebDAV API without a password and the content should be "Random data"
    And the public should be able to download the last publicly shared file using the new public WebDAV API without a password and the content should be "Random data"
    And the public upload to the last publicly shared file using the old public WebDAV API should fail with HTTP status code "403"
    And the public upload to the last publicly shared file using the new public WebDAV API should fail with HTTP status code "403"

    Examples:
      | ocs_api_version | ocs_status_code | public-webdav-api-version |
      | 1               | 100             | old                       |
      | 2               | 200             | old                       |

And only 2 examples need to run - they just do more Then checks.

We can't do it like that because of testing on oCIS.

But we could write more general Then steps for the public WebDAV API:

    And the public should be able to download the last publicly shared file using all supported public WebDAV API versions without a password and the content should be "Random data"
    And the public upload to the last publicly shared file using all supported public WebDAV API versions should fail with HTTP status code "403"

And the step code implementation for such steps can have the knowledge that the "old" public WebDAV API is not supported on oCIS, and so, on oCIS, it will not bother to test the "old" case. But on oC10 it will test both "old" and "new".

That will save quite a few scenario examples (less run-time).

It will also mean that when people add new test scenarios, they won't have to remember to paste in all that "double Example table with skip tags template" - the underneath code will already understand what to do for each type of system-under-test.