diff --git a/test/integration/connect/envoy/README.md b/test/integration/connect/envoy/README.md
index deb169ee55..a97acc710a 100644
--- a/test/integration/connect/envoy/README.md
+++ b/test/integration/connect/envoy/README.md
@@ -27,13 +27,22 @@ Where `case-basic` can be replaced by any directory name from this directory.
 `TestEnvoy/case-basic` and `TestEnvoy/case-wanfed-gw`.
 2. The real framework for this test suite lives in `run-tests.sh`. Under the hood, `main_test.go` just runs `run-tests.sh` with
    various arguments.
-3. The tests use your local code by building a Docker image from your local directory just before executing. 
+3. The tests use your local code by building a Docker image from your local directory just before executing.
+   _Note:_ this is implemented as the `docker-envoy-integ` Makefile target which is a prerequisite to the `test-envoy-integ` target,
+   so if you are running the tests by invoking `run-tests.sh` or `go test` manually, be sure to rebuild the Docker image to ensure
+   you are running your latest code.
 4. The tests run Docker containers connected by a shared Docker network. All tests have at least one Consul server running and then
    depending on the test case they will spin up additional services or gateways. Some tests run multiple Consul servers to test
-   multi-DC setups.
+   multi-DC setups. See the [`case-wanfed-gateway` test](./case-wanfed-gw) for an example of this.
 5. At a high level, tests are set up by executing the `setup.sh` script in each directory. This script uses helper functions
    defined in `helpers.bash`. Once the test case is set up, the validations in `verify.bats` are run.
-6. In CI, the tests are executed against different Envoy versions and with both `XDS_TARGET=client` and `XDS_TARGET=server`.
+6. If there exists a `vars.sh` file in the top-level of the case directory, the test runner will source it prior to invoking
+   the `run_tests`, `test_teardown` and `capture_logs` phases of the test scenario.
+7. If there exists a `capture.sh` file in the top-level of the case directory, it will be executed after the test is done, but prior to
+   the containers being removed. This is useful for capturing logs or Envoy snapshots for debugging test failures.
+8. Any files matching the `*.hcl` glob will be copied to the container `$WORKDIR/$CLUSTER/consul` directory prior to running the tests.
+   This is useful for defining Consul configuration for each agent process to load on start up.
+9. In CI, the tests are executed against different Envoy versions and with both `XDS_TARGET=client` and `XDS_TARGET=server`.
    If set to `client`, a Consul server and client are run, and services are registered against the client. If set to `server`,
    only a Consul server is run, and services are registered against the server. By default, `XDS_TARGET` is set to `server`.
    See [this comment](https://github.com/hashicorp/consul/blob/70bb6a2abdbc5ed4a6e728e8da243c5394a631d1/test/integration/connect/envoy/run-tests.sh#L178-L212) for more information.
@@ -45,4 +54,15 @@ Where `case-basic` can be replaced by any directory name from this directory.
   replaced with the name of the directory, e.g. `case-basic`.
 * Locally, all the logs of the failed test will be available in `workdir` in this directory.
 * You can run with `DEBUG=1` to print out all the commands being run, e.g. `DEBUG=1 make test-envoy-integ GO_TEST_FLAGS="-run TestEnvoy/case-basic"`.
-* If you want to prevent the Docker containers from being spun down after test failure, add a `sleep 9999` to the `verify.bats` test case that's failing.
\ No newline at end of file
+* If you want to prevent the Docker containers from being spun down after test failure, add a `sleep 9999` to the `verify.bats` test case that's failing.
+
+## Creating a New Test
+
+Below is a rough outline for creating a new test. For the example, assume our test case will be called `my-feature`.
+1. Create a new directory named `case-my-feature`
+2. If the test involves multiple datacenters/clusters, create a separate subdirectory for each cluster (eg. `case-my-feature/{dc1,dc2}`)
+3. Add any necessary configuration to `*.hcl` files in the respective cluster subdirectory (or the test case directory when using a single cluster).
+4. Create a `setup.sh` file in the case directory
+5. Create a `capture.sh` file in the case directory
+6. Create a `verify.bats` file in the case directory
+7. Populate the `setup.sh`, `capture.sh` and `verify.bats` files with the appropriate code for running your test, validating its state and capturing any logs or snapshots.
diff --git a/test/integration/connect/envoy/run-tests.sh b/test/integration/connect/envoy/run-tests.sh
index 1aa9cd79e3..43e0925c6c 100755
--- a/test/integration/connect/envoy/run-tests.sh
+++ b/test/integration/connect/envoy/run-tests.sh
@@ -180,7 +180,7 @@ function start_consul {
   # xDS sessions are served directly by a Consul server, and another in which it
   # goes through a client agent.
   #
-  # This is nessasary because servers and clients source configuration data in
+  # This is necessary because servers and clients source configuration data in
   # different ways (client agents use an RPC-backed cache and servers use their
   # own local data) and we want to catch regressions in both.
   #