It turns out to be also a very good way to test a networking library by implementing it. Since your stack needs to be able to basically handle most adverse events properly.
Yes, I found toxiproxy first, but the client-server model didn't suit me, while speedbump is perfect for my use case — simulating HTTP latency.
I am developing a progress bar for a web crawler, and testing on localhost is too fast to notice if there is any issue. With speedbump, I just do `podman run --net=host kffl/speedbump:latest --latency=1s --port=8001 localhost:8000` and test my crawler on http://localhost:8001
I believe a similar approach could be achieved using toxiproxy and configuration.
The documentation at https://github.com/Shopify/toxiproxy#2-populating-toxiproxy provides insights into the process.
While it may not be as straightforward as with speedbump, the flexibility of toxiproxy makes it a viable option.
Toxiproxy primarily serves the purpose of integration into tests.
It proves particularly useful when testing features like the progress bar directly from code.
Notably, for Go applications, integration is seamless, eliminating the need for an additional application.
Instead, you can run the Toxiproxy server part directly from the codebase.
An illustrative example can be found at https://github.com/Shopify/toxiproxy/blob/main/_examples/tes....
It turns out to be also a very good way to test a networking library by implementing it. Since your stack needs to be able to basically handle most adverse events properly.
The idea behind 'chaos engineering' is cool.