Expand API acceptance tests

[phil-davis]

For each area of API do something like:

• split the existing (usually long) feature file into smaller features. Often that can be done logically by endpoints, and the methods on those endpoints (PUT, GET, DELETE...). e.g. the provisioning API splits easily into addUser, getUser, deleteUser, addGroup, getGroup, deleteGroup... features.
• identify endpoints that do not seem to have any scenarios. Make empty feature files for those.
• review each feature file, and make the scenarios cover:
  • doing actions as an admin
  • doing actions as a subadmin (where appropriate)
  • doing actions as an ordinary user (which may be supposed to pass or fail depending on the particular endpoint)
  • using the endpoint without giving any authentication (for most things this is expected to fail)
  • giving the resource (e.g. file/folder/calendar...) different permissions (where appropriate)
• make some scenarios for an API "area" that check that it works using an app password
• think about system settings that change the behavior of the API endpoint (e.g. sharing has a lot of settings that can enable/disable various things in sharing). Make scenarios that change settings and test the changed behavior.

When writing test scenarios, as well as testing the OCS and/or HTTP status response, "always" (=as much as possible) have Then steps that confirm that the action did happen (e.g. a group now exists after the test has created it) or that some sensible data was returned in the response (e.g. for GET). For actions that are expected to fail, check that the response data is empty, or the group does not exist or... The principle here is "do not just believe everything is good because the HTTP status says so".

API areas:

• Provisioning v1 and v2 - sub-issue Expand provisioning API acceptance tests #31533
• Sharing (DAV v1 and v2) - sub-issue Expand sharing API acceptance tests #31531
• Capabilities
• WebDAV "working with files" - sub-issue Expand webDAV API acceptance tests #32366
• Case-sensitive file names Acceptance Tests for case-sensitive file names #32357
• Comments
• Favorites
• Quota
• Tags
• Trashbin
• Versions - sub-issue Expand versions API acceptance tests #31535
• Federated sharing
• Calendars

[phil-davis]

@paurakhsharma we discussed some of this today. The basics of Provisioning is now good. Maybe you can review that, specially to see where there could be improved/more Then tests for scenarios.

Then move on to another API area.

Comments please from others about the general approach that I have outlined above - if you think there is anything missing, or too much or...

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[phil-davis]

This will be ongoing for a while yet. I need to review and update progress status!

[individual-it]

is there anything we can tick off the list by now?