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

Building up E2E Tests for ORAS #523

Closed
shizhMSFT opened this issue Aug 23, 2022 Discussed in #485 · 2 comments · Fixed by #828
Closed

Building up E2E Tests for ORAS #523

shizhMSFT opened this issue Aug 23, 2022 Discussed in #485 · 2 comments · Fixed by #828
Assignees
Labels
E2E testing End-to-end testing related issues or pull requests
Milestone

Comments

@shizhMSFT
Copy link
Contributor

Discussed in #485

Originally posted by qweeah August 9, 2022

What is Needed

End-to-end tests that continuously validate the functional correctness of oras features.

Why it's Needed

  • As the number of supported commands grows, it's impossible to manually validate all the features before releasing.
  • Although we have unit tests for CLI, things might still go wrong after integration. Having E2E tests would at least cover high-value use cases and reduce regression.

How to

Setup Test Environment

The E2E tests should run against oras CLI binary with oras-distribution as the backend.

Choose Test Framework

Technically, there are two different directions of tools we use to build E2E test suite:

1) Use golang-native test framework to run test based on Cobra command execution calls

ginkgo + gomega

  • Pros:
    • Based on golang standard testing package, which matches tech-stack of most active contributors.
    • No change in github actions.
    • Applied by many state-of-the-art CLI projects like kubectl and frp so we have a lot of existing good practices to learn from.
  • Cons:
    • Use Cobra command execution call to mock user input, not 100% E2E.
    • Brings new dependencies in only for testing.
    • Won't be able to be reused by oras-py or other registry CLI tools sharing same UX as oras.

2) Use common Behaviour-Driven Development (BDD) tools to test the built out binary

Gherkin + godog

  • Pros:
    • Testing oras as an CLI application, 100% E2E.
    • Idomatic BDD framework.
    • The latest cucumber binary can be downloaded during test time, which brings no depedency into oras.
    • Test cases(specs) can be reused by oras-py or other registry CLI tools sharing same UX as oras.
  • Cons:
    • Extra one-time setup effort in Github actions.
    • Not Golang-native. (As far as I know) No expert in the current active contributors.

Both options provides expressive assertion that can meet oras' testing need.

Future Works
Below items are valuable but not in scope of this discussion:

  • Benchmark Test & Profiling.
  • E2E tests based on registry services from different cloud providers.

If you have any other ideas or suggestions on building the E2E test suite for oras, feel free to response below. Any comments are highly appreciated 🍻

@shizhMSFT shizhMSFT added this to the v0.15.0 milestone Aug 23, 2022
@qweeah
Copy link
Contributor

qweeah commented Aug 23, 2022

@shizhMSFT Can you assign this to me, thanks.

@qweeah
Copy link
Contributor

qweeah commented Aug 24, 2022

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E2E testing End-to-end testing related issues or pull requests
Projects
No open projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants