test (refactor): adding POC for API tests in goinkgo

[nsingla]

Creating a POC for converting Go Unit tests to use Goinkgo + Gomega. This also refactors existing tests and paves way as to how a new test should be written. But basically, proposing new requirements to write a new test:

1. Each test file should be based on how API services are grouped here: https://www.kubeflow.org/docs/components/pipelines/reference/api/kubeflow-pipeline-api-spec/ (it makes it easier to understand the grouping and the reasoning behind it)
2. Each endpoint of the service should be tested
3. Every test case per endpoint should be an independent spec (goinkgo spec)
4. Test should cover different possible combinations of the allowed payload - test plan should get reviewed with the team
5. Every method should log what action it's trying to perform and after it performs the action
6. Test Steps should be included in every test for easier reporting (WIP to define this)
7. Note that a custom matcher is required to compare the response with expected response, so rather than just verifying a single value, we should verify all metadata (so as to confirm that there is no other unexpected change)
8. GinkgoWriter is used for logging, and a very simple wrapper function is written to format the logs properly logger.go. So please use logger.Log to log anything test related. As in the end, logs are captured in a test log file per test and attached to the test report
9. Junit.xml and json reports are generated at the end of the suite, which can then be used to generate pretty html reports

New Test Structure for API tests:

    backend
        src
        test
            v2
                resources
                api
                    utils
                    custom_matcher
                        pipeline_matcher.go
                    test_file.go

This PR also contains an example of parameterized tests that is easy to expand and maintain. If a test requires new steps, please think about the scalability and readability of the test. Just some basic rules about a test:

1. A test should only test a single functionality
2. A test should be independent, i.e. not dependent on the output of another test
3. Test should be easily readable i.e. when someone reads a test case, they should be able to know what the test is trying to test and what is the expected outcome

Checklist:

• [x] You have signed off your commits
• [ ] The title for your pull request (PR) should follow our title convention. Learn more about the pull request title convention used in this repository.

[google-oss-prow[bot]]

Hi @nsingla. Thanks for your PR.

I'm waiting for a kubeflow member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[github-actions[bot]]

🚫 This command cannot be processed. Only organization members or owners can use the commands.

[mprahl]

@nsingla could you please address the CI failure and rebase?

[nsingla]

@nsingla could you please address the CI failure and rebase?

The CI failure is a genuine failure, I think its a performance issue with deleting pipeline versions with cacheEnabled=true and storage=kubernetes

Will check if this needs to be rebased off of master again (did it this morning)

[google-oss-prow[bot]]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mprahl

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• ~~OWNERS~~ [mprahl]

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment