How do you test your Rust code?


#1

One of my favourite features of Rust is the fact that testing and benchmarking is there out-of-the-box. I’d love to hear how others use testing in Rust; their experiences and how they use them.

Personally, I feel like I don’t utilise tests in Rust as effectively as I do in C#. I’m writing less tests, and I feel less confident about them. Maybe it’s because I spend more time rewriting the same sections of Rust code instead of blocking out functionality like I can in C# (a reflection on my lack of skill with Rust, rather than a reflection on the language), or maybe since I’ve been turning any tests without assertions into doc examples they’re just more spread out.

There are lots of places you can stick tests in Rust; my preference is to use an external tests crate, even though that makes internal code difficult to test.

As for benches, I find them excellent for prototyping ideas, verifying different ways to do things, and then keeping an eye on how changes impact performance. I find my benches start low-level, but then evolve into higher-level lines-in-the-sand.


#2

So as to where to stick your tests, I think there is a more or less general agreement in the community right now - and its also documented: https://doc.rust-lang.org/book/testing.html

For unit tests, create a tests module along the code that you are testing. Since it’s in a separate module it won’t be in the released artifacts. For integration tests, it makes sense to put them into its own tests directory where cargo will also pick them up. If you document your code properly those code snippets will also be tested when you run cargo test. Finally, code samples (which can also be seen as some form of tests I think) they go into the examples directory and will be tried to compile by cargo.

The whole story around benchmarking is blocked by the fact that the current approach is not considered stable, I think the community is waiting for someone to pick it up and put it up as a crate. You can go ahead and use whats in the core, but only on nightly unfortunately.

I’ve been mainly using the plain assert macros in my tests and doc examples, but more and more libraries show up. For example I discovered cargo is using a rust port of hamcrest which I always enjoyed using in other languages.


#3

I found this podcast to be pretty useful in getting me geared up at first to write more Rust tests:

I generally work in Erlang, Perl, and Javascript. Initially I felt inclined to write my Rust tests like Perl and Javascript, but much like Erlang Rust provides guarantees that keep you from needing to think so much about testing arguments to functions and so it was short time until I started writing my tests more as I do in Erlang.

When I write tests in Rust I find myself writing less overall individual tests, and the tests are more focused on ensuring I got the correct X for type Y, as opposed to higher level languages where I’m often testing around Y before I test X. The effect of this is that I enjoy writing tests more in Rust, and the fact that the testing suite is “baked-in” makes it even more convenient and smooth.

So far I have been writing unit tests and documentation tests in Rust and have been flexing those muscles as I continue to learn the language. I haven’t really started to add benchmark tests yet but I think as I build bigger and better things those will become incredibly useful.


#4

I’ve recently started adding tests to my programs. Currently I’m doing them as a mod test at the bottom of the file to test the various functions in that file. I started adding the tests because I had some fairly complex functions that I wanted to validate before running in the system as a whole.

I’m adding more and more tests now and I do like it, it’s giving me more confidence that the final program will work correctly.

Integration tests (or tests of modules and functions that interface with the database or external interfaces) I’m not planning on implementing. I’ve found in the past that the work of getting the external state correct for the tests requires more effort and little benefit.


#5

I’ll have to have a look at some alternative test frameworka for Rust, so far I haven’t found any scenarios where the built-in test runner hasn’t done what I need.


#6

I’m finding this too, C# has a tendency to leak all over the shop, so you have to be pretty rigorous with your testing to make sure all possibilities are covered, but that hasn’t been my experience with Rust so far.