rust

Hey, I wrote a thing. Thing being a piece of software. I have a collection of photos & documents that I really care about. I synch them between computers using syncthing and also run backups regularly. What I didn’t have was a way to quickly detect bitrot. Enter legdur legdur is a simple CLI program to compute hashes of large sets of files in large directory structures and compare them with a previous snapshot. [Read More]

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]

I am fascinated by the concept of fuzzing. It fits well with my desire to test weird code paths by using more of computer’s time and less that of a programmer. What is fuzzing ? It’s a type of automated testing, especially good with finding edge cases in your code. It runs totally outside of your code and knows nothing about it - it just throws random data at it. Modern fuzzers instrument your code to be able to tell if by changing input they change the code paths covered and by doing that they try to achieve maximum coverage. [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]

As I’ve been running several intro to Rust sessions throughout the last year, I’ve assembled a set of resources that help people ease into the language. Depending on your learning style you might like: Rustlings - This is a good set of starter exercises if you want to have a feeling for the language - have links to relevant book sections for each exercises so you can either start with the book or trying to figure it out yourself first. [Read More]