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

Clean e2e test example #1535

Merged

Conversation

kadel
Copy link
Member

@kadel kadel commented Mar 28, 2019

This is an example of how to write e2e tests using ginkgo that perform automatic setup and teardown.

To run this do

go test -v github.com/openshift/odo/tests/e2e -ginkgo.focus="Example of a clean test"  -ginkgo.slowSpecThreshold=120 -ginkgo.randomizeAllSpecs

-ginkgo.randomizeAllSpecs runs all test in random order. This will make sure that we don't create dependencies between tests specs (It( functions) even accidntaly, as the order of in which tests are run can't be prediceted.

You can also run tests in parallel:

ginkgo -nodes=2 -focus="Example of a clean test" slowSpecThreshold=120 -randomizeAllSpecs  tests/e2e/

nodes sets number of parallel executions

Note that you have to use ginkgo (go get github.com/onsi/ginkgo/ginkgo than $GOPATH/bin/ginkgo) to tests in parallel

I had to updated Ginkgo as the version that we were using doesn't support JustAfterEach

@kadel
Copy link
Member Author

kadel commented Mar 28, 2019

ping @amitkrout @girishramnani

@amitkrout
Copy link
Contributor

amitkrout commented Mar 28, 2019

@kadel Thanks for the pr in a quick time. Tomorrow will have a look

@girishramnani
Copy link
Contributor

great thinking of using the latest version of ginkgo 👍


// and returns the stdout, stderr and exitcode
func cmdRunner(cmdS string) (string, string, int) {
//TODO: this needs to be os independent
Copy link
Contributor

Choose a reason for hiding this comment

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

lets document this in an issue so that @amitkrout can work on making this os independent

Copy link
Contributor

Choose a reason for hiding this comment

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

@girishramnani We have issue for it #1131

@girishramnani
Copy link
Contributor

I am not seeing any helpers related to waitForCmdOut @kadel are we planning to add those or use the one in the utils?

helper.Chdir(originalDir)
}
if originalProject != "" {
helper.OcSwitchProject(originalProject)
Copy link
Contributor

Choose a reason for hiding this comment

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

Could this not cause an overlap? if oc active project is depended on. What happens if one of the parallel runs gets here first and sets a different active project, while another is working with a different project (in a single cluster context)

Copy link
Member Author

Choose a reason for hiding this comment

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

good point.
It looks like we could use SynchronizedBeforeSuite and SynchronizedAfterSuite

https://onsi.github.io/ginkgo/#managing-singleton-external-processes-in-parallel-test-suites

Copy link
Member Author

Choose a reason for hiding this comment

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

Fixed by removing those function all together, as I realized that there is a better way to do this

- package: github.com/onsi/ginkgo
version: v1.4.0
version: v1.8.0
Copy link
Contributor

Choose a reason for hiding this comment

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

+1


// CreateRandProject create new project with random name (10 letters)
// without writing to the config file (without switching project)
func OcCreateRandProject() string {
Copy link
Contributor

Choose a reason for hiding this comment

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

+1

@@ -44,11 +44,11 @@ func TestOdo(t *testing.T) {
RunSpecs(t, "odo test suite")
Copy link
Contributor

Choose a reason for hiding this comment

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

Remove the suite function in a separate file to isolate it form the actual test

For example:

Create a file odo_suite_test.go

package e2e

import (
	"testing"

	. "github.com/onsi/ginkgo"
	. "github.com/onsi/gomega"
)

func TestOdo(t *testing.T) {
	RegisterFailHandler(Fail)
	RunSpecs(t, "odo test suite")
}

Copy link
Member Author

Choose a reason for hiding this comment

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

This PR is intended to provide just a clean direction and template how we can structure our tests.
This should be part of a cleanup effort in a separate PR.

@amitkrout
Copy link
Contributor

I am not seeing any helpers related to waitForCmdOut @kadel are we planning to add those or use the one in the utils?

@girishramnani I think its just a templates for our reference to write the test. Those functions are in utils can be moved under helper package in the subsequent improvement of this pr template.

Copy link
Contributor

@amitkrout amitkrout left a comment

Choose a reason for hiding this comment

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

It make more sense if you rename file name as template_cleantest_test.go.

@amitkrout
Copy link
Contributor

Test went fine locally and the interesting part is that with four node parallel execution the total run time reduces to half compare to serial execution of the same template.

Test structure looks good to me.

@kadel
Copy link
Member Author

kadel commented Mar 29, 2019

/retest
aws error

Expect(err).NotTo(HaveOccurred())

originalProject = helper.OcCurrentProject()
})
Copy link
Member

Choose a reason for hiding this comment

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

If these will be ran for each and every test, would it make sense to try to put as much information as possible into the utility functions / helper files?

@amitkrout
Copy link
Contributor

@kadel Rebase and fix the formatting issue

$ make validate
./scripts/check-gofmt.sh
gofmt ERROR - These files are not formated by gofmt:
./tests/e2e/template_cleantest_test.go
make: *** [gofmt] Error 1

@kadel
Copy link
Member Author

kadel commented Apr 1, 2019

ping @amitkrout @girishramnani

Copy link
Contributor

@amitkrout amitkrout left a comment

Choose a reason for hiding this comment

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

Test structure is quite impressive. Tested the template locally without any issue. @girishramnani We need to push this pr ASAP.

@amitkrout
Copy link
Contributor

/approve

@openshift-ci-robot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: amitkrout

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

1 similar comment
@openshift-ci-robot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: amitkrout

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. Required by Prow. label Apr 1, 2019
@girishramnani
Copy link
Contributor

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. Required by Prow. label Apr 1, 2019
@openshift-merge-robot openshift-merge-robot merged commit 7c81a21 into redhat-developer:master Apr 1, 2019
@rm3l rm3l added the estimated-size/XXL (60 - ??) Rough sizing for Epics. More than 3 sprints of work for one person label Jun 18, 2023
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. Required by Prow. estimated-size/XXL (60 - ??) Rough sizing for Epics. More than 3 sprints of work for one person lgtm Indicates that a PR is ready to be merged. Required by Prow.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants