rust-testing-tricks

Being able to precisely control what failures in underlying systems occur and at what time can be really useful in achieving a fast and stable test suite. While I am a big proponent of dependency inversion and being able to control dependencies via the explicit injection points in your API, sometimes it’s impractical to do so. This is where fail can help us immensely, providing an escape hatch for situations like those as it allows to inject failures into previously defined failure points. [Read More]

Sometimes you just have a bunch of example data laying around and you want to make sure your code works with all of them. Some of them are probably short and sweet and could live happily as doctests, which are amazing btw. But some of them are more awkward to present in such form, because, for example, of their size or number. Typically when you have an example of how the program should behave you write an example-based unit test. [Read More]

Use verbs as test module names Who said that the test module needs to be named test ? Experiment with different module names, pay attention to how the test runner displays the results. A structure that I like, an example: worker.rs: // some production code here mod should { #[test] fn consume_message_from_queue() { // mock queue, create worker with that queue injected // start worker // check if queue's 'get_message' was invoked } } Cargo prints worker::should::consume_message_from_queue when running this test, which reads nicely and exposes the requirement. [Read More]

Rust: controlling side effects from the test. Hello and welcome to the newest episode on testing in Rust. Imagine you want to write a timestamping repository of some sorts, that will associate the timestamp of when the storage operation was invoked with the stored value. How to write it in Rust ? And more importantly - how to test it ? I would like to share a solution I found and talk a bit about how it works. [Read More]