- Remove the logic from the constructors
- Have start take a configuration map for the fixture processes
- Move the testing on open ports closer to the actual start
If $KUBE_ASSETS_DIR is set, we use that and try to run the binaries from
within that directory.
If it is not set, we try to determine the assets directory as a relative
path to the test suite.
- APIServer & Etcd get configured, from the outside, on which ports to
listen on
- Configuration, the subjects under test might be interested in, is
exposed by Fixtures.Config
Hint: Before we start any process, we get a random port and check if
that random port is acutally free to bind to. As it takes some time
until we actually start anything, we might run into cases, where another
process binds to that port while we are starting up. Even if we do the
port checking closer to actually binding, we still have the same issue.
For now, however, we take that risk - if we run into problems with that,
we are open to refactor that.
We're not exercising the test framework yet, but it's in place.
Our democli expects its test assets to be in `./assets/bin`. We have a
script `./scripts/download-binaries.sh` which will populate that directory
from a google storage bucket.
Once those assets are in place, you can run tests with
`./scripts/run-tests.sh`.
We use [ginkgo](http://onsi.github.io/ginkgo/) and
[gomega](http://onsi.github.io/gomega/) for testing. We generate some
boilerplate with:
```
mkdir integration
cd integration
ginkgo bootstrap
ginkgo generate integration
```
We use
[gexec](http://onsi.github.io/gomega/#gexec-testing-external-processes)
to compile and run the CLI under test, and to inspect its output.
We use `dep ensure` to ensure that all our dependencies are properly
vendored. From now on, this will be our workflow with every commit.
Hannes Hörl