-
Notifications
You must be signed in to change notification settings - Fork 162
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
acceptance: bazelify remaining tests, cleanup python framework (#4183)
* bazelify `acceptance/trc_update` * remove `acceptance/reconnecting` This was a false positive that cannot be fixed easily. The test tried to restart the dispatcher for the control service, to see that reconnecting to the dispatcher works. Unfortunately, with the docker-compose file created by topogen, the control service container uses the dispatcher's network context (`network_mode: service:scion_disp_cs_...`). In this configuration, network access never recovers after the referenced container goes away. This test cannot be made to work without changing the topogen docker-compose setup, which does not seem to be worth the trouble. The test had been passing because it used a bad regex to that failed to match the dispatchers it tried restart. This test could be replaced with a more focused integration test that checks the interaction of the reconnector logic with a restarted dispatcher. * remove acceptance bash framework, it's all bazel now * simplification and cleanup pass over the acceptance/common python framework
- Loading branch information
Showing
32 changed files
with
506 additions
and
1,339 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -18,4 +18,3 @@ export PARALLELISM=1 | |
|
||
cat .buildkite/pipeline.yml | ||
gen_bazel_test_steps //acceptance | ||
gen_acceptance ./acceptance |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,63 +1,44 @@ | ||
# Acceptance testing framework | ||
|
||
To add an acceptance test, create a new `xxx_acceptance` folder in | ||
`/acceptance`, with `xxx` replaced by the name of your test. | ||
|
||
The folder must contain a `test` executable, which must support the following arguments: | ||
|
||
* `name`, which returns the name of the acceptance test. | ||
* `setup`, which runs the setup portion of the acceptance test. If the return | ||
value of the application is non-zero, the test is aborted. | ||
* `run`, which runs the test itself (including assertions). If the return value | ||
of the function is non-zero, the test is considered to have failed. | ||
* `teardown`, which cleans up after the test. If the return value of the | ||
function is non-zero, the run of the **entire** test suite is aborted. | ||
|
||
For an example, see `acceptance/reconnecting_acceptance`. | ||
This directory contains a set of integration tests. | ||
Each test is defined as a bazel test target, with tags `integration` and `exclusive`. | ||
|
||
## Basic Commands | ||
|
||
To run all defined tests, use: | ||
|
||
```bash | ||
acceptance/run | ||
``` | ||
|
||
To run only the tests matching a certain regular expression, use: | ||
To run all acceptance tests, execute one of the following (equivalent) commands | ||
|
||
```bash | ||
acceptance/run REGEX | ||
make test-acceptance # or, | ||
bazel test --config=acceptance_all # or, | ||
bazel test --config=integration //acceptance/... //demo/... | ||
``` | ||
|
||
where `REGEX` is replaced with a regular expression of your choice. | ||
|
||
## Manual Testing | ||
|
||
To run fine-grained operations for a single test, use one of the following: | ||
Run a subset of the tests by specifying a different list of targets: | ||
|
||
```bash | ||
acceptance/ctl setup TESTNAME | ||
acceptance/ctl run TESTNAME | ||
acceptance/ctl teardown TESTNAME | ||
bazel test --config=integration //acceptance/cert_renewal:all //acceptance/trc_update/... | ||
``` | ||
|
||
This calls the functions in `acceptance/xxx_acceptance/test.sh` directly, | ||
without any prior setup. This also means docker images are **not** rebuilt, | ||
even if application code has changed. | ||
The following the flags to bazel test can be helpful when running individual tests: | ||
|
||
To run the `ctl` commands above, the environment needs to be built first. To do that, run: | ||
- `--test_output=streamed` to display test output to the screen immediately | ||
- `--cache_test_results=no` or `-t-` to re-run tests after a cached success | ||
|
||
```bash | ||
acceptance/ctl gsetup | ||
``` | ||
|
||
This will also rebuild the docker images, taking new code into account. | ||
## Manual Testing | ||
|
||
To run the `setup`, `run` and `teardown` phases of a single test (without gsetup): | ||
Some of the tests are defined using a common framework, defined in the | ||
bazel rules `topogen_test` and `raw_test`. | ||
These test cases allow more fine grained interaction. | ||
|
||
```bash | ||
acceptance/ctl grun TESTNAME | ||
# Run topogen and start containers, or other relevant setup | ||
bazel run //<test-package>:<target>_setup | ||
# Run the actual test | ||
bazel run //<test-package>:<target>_run | ||
# ... interact with setup, see state in /tmp/artifacts-scion ... | ||
# Shutdown and cleanup | ||
bazel run //<test-package>:<target>_teardown | ||
``` | ||
|
||
Note that `acceptance/ctl` will not save artifacts on its own, and all output | ||
is dumped on the console. | ||
See [common/README](common/README.md) for more information about the internal | ||
structure of these tests. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
Oops, something went wrong.