m3talux
commented
6 months ago Here is a summary of how we tested the library internally before releasing it to the public:
- All of our microservices are tested via cucumber testing, using the following library: https://github.com/cucumber/godog a. We test that the setup is correct: Queues, bindings, and exchanges are up and ready b. We test that events are well received and consumed c. We test that events are emitted and present in the target queue
- For the keep-alive and fault-tolerant mechanisms, we use a technique called "Chaos testing": a. We drop the RabbitMQ server at random points in time b. We make sure microservices keep functioning normally c. We up the RabbitMQ server d. We make sure that the cache is emptied (events are sent/consumed) and that events are flowing normally e. Logs help a ton to trace any unwanted or unexpected error.
By following the 2 points for almost 3 years, we have continuously confirmed and re-confirmed that Gorabbit is as solid as we wanted it to be.
Now, to provide something similar to Gorabbit and offer a metric that users can trust, I suggest a very similar approach:
- Cucumber tests that will cover the client's functionalities: Publishing/Consuming and the manager's functionalities: set up.
- Chaos testing for the keep-alive mechanisms: A container-based approach that would instantiate one or many publishers/consumers and a single RabbitMQ server that would shut down at random times. We can then define a list of events we expect to be sent and evaluate that the same list is well received.
While the library looks promising and well-written, it's still risky to use new libraries instead of battle-tested ones.
It would be good to understand exactly what experience the development team has of using this library internally, what results it produces, and how the developers themselves assess its readiness for production.