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

Convert e2e go tests to ginkgo - using ginkgo convert utility #1372

Merged

Conversation

harishsurf
Copy link
Contributor

Description of the change:
This change converts all the e2e tests written in vanilla go to ginkgo test. This is a first step that does basic ginkgo conversion and ensure that all the e2e tests are run successfully. There will be separate PR per test to do incremental changes to achieve full-fledge BDD driven testing.

Motivation for the change:

Reviewer Checklist

  • Implementation matches the proposed design, or proposal is updated to match implementation
  • Sufficient unit test coverage
  • Sufficient end-to-end test coverage
  • Docs updated or added to /docs
  • Commit messages sensible and descriptive

Copy link
Member

@ecordell ecordell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The initial conversion looks good!

There are a couple of failures in the e2e tests that we should double check.

Otherwise it would be great if we could spend an hour or two slightly re-naming the tests so that that output is a little more readable.

Right now I see things like:

Subscription Tests [It] subscription updates existing install plan

but part of BDD is to make the test plan read a little more naturally, in this case something like:

Subscription [It] updates an existing install plan

Small tweaks like that can make it really clear what's happening and why.

We can also be way more generous with the use of Context/It/etc. The majority of the comments in the e2e suite can probably be lines that show up as a block description.

@@ -19,172 +19,175 @@ import (
"k8s.io/kubernetes/pkg/apis/rbac"
)

func TestUserDefinedServiceAccountWithNoPermission(t *testing.T) {
defer cleaner.NotifyTestComplete(t, false)
var _ = Describe("Testing with Ginkgo", func() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we figure out better names for these top-level Describes? This one could be "User Defined ServiceAccount" and the first It could be with no permission

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ecordell, Part of the reason for not using different Containers / Spec combinations in this PR is:

  1. It will introduce a lot of changes in a single PR (difficult to comprehend and review) and this change would take a lot of time.
  2. Some of the tests, from what I understand could be restructured.

What I thought would be a better approach is to have an initial working ginkgo conversion in place and then have separate PRs to do incremental changes.

But, for this PR, I will work with someone and have a better Describe/ It names for the tests.

@openshift-ci-robot openshift-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Mar 16, 2020
Copy link
Contributor

@benluddy benluddy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a big diff, and a mostly-mechanical conversion, so I only mentioned a handful of things that stood out to me.

Evan's point about BDD and comprehensibility is a really important one -- I would prefer a test with a completely arcane implementation that tests a clearly-defined behavior versus a test that is straightforward about what it does but opaque about why it does what it does.

Be careful about long-lived feature branches! Over time, without occasionally rebasing, it can become harder to correctly resolve merge conflicts when you finally go to reintegrate your branch.

test/e2e/scoped_client_test.go Outdated Show resolved Hide resolved
test/e2e/installplan_e2e_test.go Outdated Show resolved Hide resolved
test/e2e/packagemanifest_e2e_test.go Show resolved Hide resolved
type packageManifestCheckFunc func(*packagev1.PackageManifest) bool

func packageManifestHasStatus(pm *packagev1.PackageManifest) bool {
// as long as it has a package name we consider the status non-empty

if pm == nil || pm.Status.PackageName == "" {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't mind seeing the function body rewritten to return pm != nil && pm.Status.PackageName != "", if you agree.

})
It(

// TestSubscriptionStatusMissingTargetCatalogSource ensures that a Subscription has the appropriate status condition when
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's unusual to have this chunk of single-line comments appear inside of a method invocation. Line 585 jumped out at me because I was surprised to see a string literal immediately following these lines of comments. How about putting them immediately above the It?

})
It(

// TestSubscriptionInstallPlanStatus ensures that a Subscription has the appropriate status conditions for possible referenced
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have the same comment here as the spec above, do you mind changing these (unless you disagree)?

@openshift-ci-robot openshift-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Mar 17, 2020
@benluddy
Copy link
Contributor

/retest

It looks like this may be a pre-existing flake. The last PR the touched this exhibited the same failure, but eventually passed and merged (https://openshift-gce-devel.appspot.com/pr/operator-framework_operator-lifecycle-manager/1334). If it eventually passes here, then I would like to merge this and address the flake in a follow-up to limit the number of times this change needs to be rebased.

@awgreene
Copy link
Member

/retest

@benluddy benluddy mentioned this pull request Mar 18, 2020
5 tasks
@benluddy
Copy link
Contributor

/retest

1 similar comment
@benluddy
Copy link
Contributor

/retest

@benluddy
Copy link
Contributor

/test e2e-gcp

@openshift-ci-robot openshift-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Mar 19, 2020
@openshift-ci-robot openshift-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Mar 19, 2020
@benluddy
Copy link
Contributor

/test e2e-aws-console-olm

@benluddy
Copy link
Contributor

/retest

@benluddy
Copy link
Contributor

/lgtm

Good job staying on top of this conversion! Looking forward to seeing the next steps.

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Mar 19, 2020
@openshift-ci-robot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: benluddy, harishsurf

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:

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

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Mar 19, 2020
@openshift-merge-robot openshift-merge-robot merged commit a6162e4 into operator-framework:master Mar 20, 2020
@harishsurf harishsurf deleted the ginkgo-e2e branch March 31, 2020 18:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants