tdd

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]