A recent discussion in the issues of stainless prompted me to write a small blog post that explains the basics of testing in Rust using stainless. Note that stainless only works with the nightly Rust compiler as it requires compiler plugins.
First of all, let’s set up the project. We will build a library and write unit as well as integration tests for it (code by xetra11). Here’s the Cargo.toml
file:
1 2 3 4 5 6 7 8 9 10 |
|
So now let’s look at the main entry point of the library. The code is just for illustration purposes and we don’t really care what it does. We do however care about the first three lines.
#![feature(plugin)]
tells the Rust compiler to turn on support for compiler plugins. As stainless is a compiler plugin this is needed.
The line after that is a bit more complicated. It does the following: It first checks if we are currently compiling for testing (e.g. running cargo test
) If that is the case then we add the line #![plugin(stainless)]
which enables stainless. If we don’t compile for testing then we do nothing, i.e. we don’t enable stainless when compiling normally (e.g. when running cargo build
) See this blog post for an in depth explanation if cfg_attr
.
And then we define a submodule called test
. This is where we will write our unit tests.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 |
|
Alright, so let’s have a look at the unit tests. First we configure the module as a test module (doesn’t need to be compiled normally). Then we add our use
declarations for the things we want to use in our tests. Due to implementation details of stainless we need to pub use
. And they also need to be outside of the describe!
blocks.
And then we come to the actual things added by stainless. describe!
, before_each
, and it
. If you know rspec then this will look very familiar. it
is used to define individual tests and describe!
is used to group tests. And before_each
is executed before each test in a group of tests.
If you look closely you will notice that due to the fact that the test module is a submodule of the code that we’re testing we have access to private functions and private struct fields.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
|
Oh, and as we’re writing a library we of course should also write integration tests. These go into the tests/
folder of the project. It looks similar to our unit tests, but a few things are different:
- We can just use
#![plugin(stainless)]
as we will never compile this code outside of our tests. - We need to add the library we’re building as an external crate (through
extern crate renderay_rs;
) as this is a separate executable. - We cannot use private functions of struct fields here. So we need to use
Canvas::new
and a getter for the array.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
|
And running the tests looks like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|