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

[registry-operator]: end-to-end testing framework #6

Open
shanduur opened this issue Feb 28, 2024 · 4 comments · Fixed by #20 · May be fixed by #23
Open

[registry-operator]: end-to-end testing framework #6

shanduur opened this issue Feb 28, 2024 · 4 comments · Fixed by #20 · May be fixed by #23
Assignees
Labels
area/registry-operator Issues or PRs related to registry-operator. kind/discussion ADR discussions.

Comments

@shanduur
Copy link
Member

Context and Problem Statement

Ensuring the reliability and functionality of the registry-operator is essential to maintain a seamless experience for developers and DevOps teams utilizing CNCF Distribution Registry instances. End-to-end testing plays a critical role in validating the deployment, scaling, and management capabilities of the registry-operator across various scenarios.

The selection of an appropriate end-to-end testing framework is paramount to establish robust testing standards and practices. Factors such as adherence to language idioms, support for testing complex workflows, community adoption, and extensibility are crucial considerations in this decision-making process.

Considered Options

  • Radish (Python)

    • Description: Radish is a behavior-driven development (BDD) framework for Python, offering a structured approach to end-to-end testing.
    • Pros: BDD approach fosters collaboration between stakeholders, human-readable scenarios, support for Gherkin syntax.
    • Cons: Limited adoption and community support compared to other Python testing frameworks.
  • pytest-bdd (Python)

    • Description: pytest-bdd is a plugin for pytest that allows for behavior-driven testing using Gherkin syntax.
    • Pros: Seamless integration with pytest, extensive plugin ecosystem, active development and community support.
    • Cons: Potential learning curve for teams unfamiliar with pytest and BDD principles.
  • behave (Python)

    • Description: Behave is another Python BDD framework, enabling collaboration between stakeholders through human-readable behavior specifications.
    • Pros: Well-established in the Python BDD community, supports Gherkin syntax, extensive documentation.
    • Cons: Configuration overhead, may be slower compared to pytest-based frameworks.
  • Ginkgo and Gomega (Go)

    • Description: Ginkgo is a BDD-style testing framework for Go, and Gomega is its companion matcher library.
    • Pros: Integrates well with Go's testing package, readable and expressive test specifications.
    • Cons: No support for Gherkin syntax, promotes non-idiomatic Go practices.
  • testing (Go)

    • Description: The standard testing package in Go provides a simple and effective way to write tests.
    • Pros: Minimalist approach, built-in to the Go language, lightweight and fast test execution.
    • Cons: Lacks BDD-style features, may require more effort to structure tests for complex scenarios compared to BDD frameworks.
@shanduur shanduur added area/registry-operator Issues or PRs related to registry-operator. kind/discussion ADR discussions. labels Feb 28, 2024
@shanduur shanduur self-assigned this Mar 29, 2024
@shanduur
Copy link
Member Author

shanduur commented Mar 29, 2024

I've done some initial investigation and I really enjoy pytest-bdd. It has huge community, easily integrates with feature files written with Gherkin syntax, and as it is a pytest plugin, it can benefit from multiple other pytest plugins.

Also, dependency management with Poetry is frictionless. It also easily integrates with linting tools, providing single file for configuration management for many, e.g. mypy, black, isort.

tests
├── README.md
├── e2e
│   ├── __init__.py
│   ├── features
│   │   └── sanity.feature
│   ├── framework
│   │   ├── __init__.py
│   │   ├── kubernetes.py
│   │   └── utils.py
│   └── test_sanity.py
├── poetry.lock
└── pyproject.toml

@malgorzatadutka
Copy link
Contributor

I'd like to use testing (Go) for the unit tests, Ginkgo doesn't have integration with feature files. Radish and pytest-bdd are quite similar. I would choose pytest-bdd with the community support.

@purpleturtll
Copy link

+1 for pytest-bdd. Seems to be the most "getting out of your way" when writing scenarios.

shanduur added a commit that referenced this issue Apr 14, 2024
# Proposed Architectural Decision Record (mADR)

## Checklist

- [x] The context and problem statement are clearly articulated.
- [x] The considered options are listed with relevant links or
references.
- [x] The chosen option is clearly stated along with the rationale.
- [x] The mADR template is filled out accurately.
- [x] Any additional information or references are included.

<!-- Link to the discussion -->
Closes #6

Signed-off-by: Mateusz Urbanek <mateusz.urbanek.98@gmail.com>
@shanduur shanduur reopened this Apr 30, 2024
@shanduur
Copy link
Member Author

shanduur commented Apr 30, 2024

Reopening.

One more option worth considering:

  • Kyverno Chainsaw (low-code, YAML)
    • Description: Kyverno Chainsaw is a low-code and declarative tool for testing Kyverno policies and running end-to-end tests in Kubernetes clusters.
    • Pros: easy to use (low-code), declarative, advanced assertions, more flexible than KUTTL, built for testing operators;
    • Cons: strongly opinionated.

@shanduur shanduur linked a pull request Apr 30, 2024 that will close this issue
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/registry-operator Issues or PRs related to registry-operator. kind/discussion ADR discussions.
Projects
Status: In Progress
3 participants