diff --git a/README.md b/README.md index 1b9a5df..20d003a 100644 --- a/README.md +++ b/README.md @@ -29,6 +29,7 @@ Page 5: - [Purpose](#purpose) - [Todo](#todo) - [Deployment](#deployment) +- [Functional testing](#functional-testing) - [Local example](#local-example) @@ -76,6 +77,17 @@ For those curious, this repo using GitHub Actions to publish [packages](https:// Another alternative would be to have GitHub Actions deploy to Portainer directly, which would give me a much more normal CICD pipeline. I didn't do this because currently my Portainer instance is only accessible via my [Tailscale](https://tailscale.com/) network and I'd have to expose it to the Internet to allow GitHub Actions access it. But I'm sure I could whitelist GitHub to access it with network policies. +## Functional testing +This repo includes mock and live functional testing. Some people would instead use these terms: integration testing, API testing, component testing. Regardless, these are external tests of the API via HTTP requests. These types of tests are nice for a project like this because we can write one test and use it on all of the existing implementations (or future ones if I add more languages) since they should provide the exact same API. + + + +The live-functional-tests just do some very basic checks to ensure the live containers are appropriately configured for their dependencies. + +The majority of the logic is tested in the mock-functional-test, where we control everything that the fanout is doing. For example, we can mock out a specific set of data to be returned and write our tests against it. We won't have to worry about data changing in the live dependency that breaks out tests. + +Furthermore, we can inject some faults into the system to see how our application reacts when encountering problems. The way I've done it here is to use (abuse?) the "X-Forwarded-For" (XFF) header, which is forwarded to the dependency so they can see the originating IP (sometimes this is required to support rate limiting when proxies are involved). I've configured my "mock-4channel" application to delay its response when it sees the XFF signal `4c-mock-delay=N` with "N" being the number of seconds to delay. This means, the person writing mock-functional-tests can just alter the XFF being sent into the application which allows them easily test the timeout logic. + ## Local example ```sh diff --git a/docs/img/glue-functional-testing.drawio.png b/docs/img/glue-functional-testing.drawio.png new file mode 100644 index 0000000..36df714 Binary files /dev/null and b/docs/img/glue-functional-testing.drawio.png differ