Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve Then steps in API acceptance tests #39512

Closed
phil-davis opened this issue Nov 22, 2021 · 5 comments
Closed

Improve Then steps in API acceptance tests #39512

phil-davis opened this issue Nov 22, 2021 · 5 comments
Labels

Comments

@phil-davis
Copy link
Contributor

phil-davis commented Nov 22, 2021

We run the core API acceptance tests in various different environments including:

  • regular owncloud/core
  • oC10 apps (for example, user_ldap, files_primary_s3, admin_audit, activity, password_policy...) where significant different backend components, hooks, events happen for those apps, and there can potentially be any sort of regression of behavior.
  • owncloud/ocis which has a completely different server-under-test
  • cs3org/reva which has a completely different server-under-test

When steps are expected to run just the When action, and not fail. The later Then steps in the scenario should check the result of the When step. We do this because:

  • sometimes a When step is expected to sometimes give a "bad" HTTP status. For example, if dome with a valid user the API request returns 2xx, if done with a non-existent user it gives a 4xx. So the When step code cannot and should not guess if a 4xx is "a bad thing".
  • in API tests we want to be clear about what are the expected results of the When action. So writing out the expected HTTP status, and something about the expected request body etc in separate Then steps is useful for people who read the scenario. (rather than hiding this inside the test code as "assumed knowledge")

Issue owncloud/ocis#1420 has a discussion about this. In that case the scenario did not have Then steps to check the HTTP status. The test for public link access failed, and it was not clear that actually the When step failed completely.

ToDo: add Then steps to existing API test scenarios to better check the results of When steps.

@phil-davis
Copy link
Contributor Author

Whoever starts this, please do an initial PR that just adjusts a single API feature file. Then we can all review and discuss to make sure we choose a "best" way forward.

@phil-davis
Copy link
Contributor Author

Note: there are some simple examples done for disable-user tests at commit 6e5eb23

@kiranparajuli589
Copy link
Contributor

@grgprarup is working on this

@grgprarup
Copy link
Contributor

grgprarup commented Feb 15, 2022

API acceptance tests suites to cover:

A single PR for a single suite would be greatly appreciated.

@sushmita56 sushmita56 linked a pull request Feb 17, 2022 that will close this issue
10 tasks
@grgprarup grgprarup removed their assignment Apr 28, 2022
@SagarGi SagarGi removed their assignment May 3, 2022
@kiranparajuli589
Copy link
Contributor

finally done! great work @SagarGi, @amrita-shrestha, @grgprarup and @sushmita56 👑 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants