Review upload conflict webUI tests

[phil-davis]

Some webUI tests upload a file over an existing file. They either overwrite the existing file or "keep both copies". e.g. webUIUpload/uploadEdgecases.feature

The tests are using files locally from the skeleton. This is convenient, but:

1. It assumes that the test runner environment has a local copy of the testing app (where the skeleton files live)
2. The local skeleton files overwrite existing files in the user account that have identical content anyway. So it is not possible to check the final content on the server to verify that an overwrite did or did not happen.

Review these tests, and any tests that assume that skeleton files are available locally to the test runner.
Refactor them to avoid the isssue.

[ownclouders]

GitMate.io thinks possibly related issues are #22492 (test), #31579 (test), #22485 (test), #31408 (Add scenario result to webUI test output), and #32143 (MinkSelenium2Driver recent change breaks webUI tests).

[individual-it]

The webUI tests use files from filesToUpload to upload files. There are @Then steps that check that files did not change, to make that comparison the skeleton folder is used. From where else could we get the information about what the content of the original file was?

[phil-davis]

Option 1) In a folder under tests/acceptance, the test runner code could have a local copy of the files that are expected to be in the skeleton (API and webUI skeletons).

Option 2) Forget about skeleton files. When we want to test that upload/download works, first upload a local file from FilesForUpload, then download it and make sure the content is the same. When we want to test upload-overwrite, first upload file.txt with ssome content. Then upload file.txt with some different content, then download file.txt and check the content is what you expect.

Using option 2 means that you cannot check that an original skeleton file is correctly served for download, because the test runner will have no "absolutely correctly known" knowledge about what the content of the skeleton file should be.

Note: the tests that make use of skeleton files already "know" the names of skeleton files. Those names are written in the test scripts. So option 1 is already partly implemented anyway - the test runner has "duplicate" knowledge about the file and folder names that exist in the skeleton.