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

Proposal: split e2e tests into their respective repositories #17

Open
Cryptophobia opened this issue Mar 21, 2018 · 5 comments
Open

Proposal: split e2e tests into their respective repositories #17

Cryptophobia opened this issue Mar 21, 2018 · 5 comments

Comments

@Cryptophobia
Copy link
Member

From @arschles on January 19, 2016 23:10

For example, all the tests that use the deis CLI to run stuff against the controller, should be back in deis/workflow and the git push tests should be in deis/builder. This repository should pull all those tests together and run them in a harness.

Copied from original issue: deis/workflow-e2e#26

@Cryptophobia
Copy link
Member Author

From @arschles on January 19, 2016 23:17

Requesting comments/ideas @jchauncey @slack @sgoings

@Cryptophobia
Copy link
Member Author

From @arschles on January 19, 2016 23:35

@mboersma I know you have some PRs in flight right now, so let me know when you're done and I'll begin the split-out process

@Cryptophobia
Copy link
Member Author

From @sgoings on January 20, 2016 21:43

How would one "run all the e2e tests" after this split up?

@Cryptophobia
Copy link
Member Author

From @jchauncey on January 21, 2016 16:7

So my first thought is to do the following:

  1. individual components have a directory that contains all the necessary go code to produce a binary that can be run to fully test that component. So for example logger would have a logger_test binary (producible out of the e2e testing directory). This would allow developers to run this test against an existing kubernetes cluster by filling in a few pieces of information like the k8s api. (In a container of course)
  2. This part is still up for some debate:
    2a. We pull in all the component e2e testing directories as deps in a larger project and build all the binaries there. Package those up in a container and have a master script call each binary to run those tests.
    2b. Pull in all the deps and have a master testing binary for the full e2e suite.

@Cryptophobia
Copy link
Member Author

From @arschles on January 21, 2016 16:21

I agree mostly with @jchauncey. Specifically, each component can have a package called tests or similar, and ginkgo build can make a test binary from that code. We can also build a docker image around that binary for testing inside k8s as he said.

However, we can construct that code in such a way that this repository can import into a "master" binary, which we can also ginkgo build into a binary and build a docker image around that binary as well.

I hope I've explained that sufficiently It'll be fairly self explanatory after showing a prototype for a test or 2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant