Add a brief explanation of testing

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. 
+
+<img src="./docs/img/glue-functional-testing.drawio.png">
+
+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