Uploaded image for project: 'OpenShift GitOps'
  1. OpenShift GitOps
  2. GITOPS-8280

E2E Testing for ApplicationSet Wildcards

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • Operator
    • None

      Story (Required)

      • As a Developer, I want to add an End-to-End (E2E) test case to the CI pipeline, so that we can ensure the wildcard functionality works in a real Kubernetes environment and prevent future regressions.

      Background and Approach (Required)

      • Unit tests mock the Kubernetes API, but we need to verify the interaction between the Operator, the Kubernetes API Server, and the ApplicationSet controller. 
      • The technical approach involves adding ginkgo testing that:
        • Creates a target namespace.
        • Configures the CR with a wildcard.
        • Deploys a test ApplicationSet into the target namespace and verify permissions.

      Out of Scope

      • The feature implementation.

      Dependencies

      Acceptance Criteria (Mandatory)

      • Given the E2E test suite, when the "ApplicationSet Wildcard" test runs, then it successfully creates a namespace appset-e2e-test and:
        • Updates the ArgoCD CR to watch appset-e2e-*.
        • it asserts that the RoleBinding exists in the target namespace.
        • it creates a dummy ApplicationSet in that namespace and verifies it is not rejected by the webhook/controller.
      • Given the CI pipeline, when a PR is opened, then this test runs and passes.

      Definition of Done

      • Code Complete:
        • All code has been written, reviewed, and approved.
      • Tested:
        • Unit tests have been written and passed.
        • Ensure code coverage is not reduced with the changes.
        • Integration tests have been automated.
        • System tests have been conducted, and all critical bugs have been fixed.
        • Tested and merged on OpenShift either upstream or downstream on a local build.
      • Documentation:
        • User documentation or release notes have been written (if applicable).
      • Build:
        • Code has been successfully built and integrated into the main repository / project.
        • Midstream changes (if applicable) are done, reviewed, approved and merged.
      • Review:
        • Code has been peer-reviewed and meets coding standards.
        • All acceptance criteria defined in the user story have been met.
        • Tested by reviewer on OpenShift.
      • Deployment:
        • The feature has been deployed on OpenShift cluster for testing.

              nmirasch@redhat.com Neus Miras Chueca
              nmirasch@redhat.com Neus Miras Chueca
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: