Is there any equivalent of Python unittest module in Rust?

Hello everyone

I would like to ask a questions about the possibilities of developing unit tests in Rust.

Based on what has been explained in The Book, we can control how tests are run or which tests are run via command line using Cargo. For example, run only those tests whose name match certain pattern.

Before start learning Rust, I started developing unit tests while I was working on a project developed in Python. I used a lot unittest module :

https://docs.python.org/3/library/unittest.html

The module gives wide access to virtually every aspect of the test (TestCase in particular). You can even extend the classes, customize error messages and above all, using unittest.TestSuite which gives you the possibility to select/add and run only a list of tests chosen by the user (so a selection of the test at the application level). I even developed a GUI (an Excel like table) where the user could indeed select via checkbox the tests he/she wished to run.

I'm a beginner in Rust and so far, I haven't found the equivalent of the above mentioned options. While I as googling I found a Nightly-only crate which is still experimental and I'm not even sure whether that is what I'm looking for

So, am I missing something? Or is that all we get in stable Rust for unit tests is just the command line via Cargo?

Is there any equivalent of Python unittest module including all structures and methods for developing unit tests and customizing them?

Thanks in advance

No, there is not. There's a basic #[test] annotation, and not much else.

There's a proposal for more functionality, but it's stuck in limbo and probably won't happen in years: eRFC: Custom test frameworks by Manishearth · Pull Request #2318 · rust-lang/rfcs · GitHub

There are many crates that implement some custom test functionality:

1 Like

Many thanks for the information you provided and for clarifying this. It's sad and a bit strange because as I understand Rust is a modern OS-level language and these projects are often very huge and quite complex. Do people really manage to get test jobs (loads of tests!) done only by command line?

It's not ideal, but workable. To me the big thing missing is machine-readable report (I have to parse text output — yuck!).

Big Rust projects aren't big monoliths. They tend to be split into many smaller crates, each with its own set of small tests.

It would be nice to programmatically generate test cases, but it's not strictly necessary, because you can just run multiple tests within a single #[test] function. It's also possible to generate test functions via macros.

Tests fail by panicking, so you can customize failure messages by panicking with whatever you want.

Filtering and #[ignore] are very basic. There's a proposal for improvement.

But I'm afraid that the current state is the case of perfect being enemy of the good. The initial MVP of testing in Cargo has stalled waiting for custom testing frameworks integration that was meant to solve all the problems for everyone, and that never came.

5 Likes

There is
cargo +nightly test -- -Z unstable-options --format json

But the output seems to be lacking crucial information.

Edit: Or more comprehensively:
cargo +nightly test --message-format=json -- -Z unstable-options --format json

Well, Rust is a modern language, and that's why it has testing built right into the tooling. It's pretty low-friction because you don't have to write additional code in order to build a test harness and generate special testing executables, etc. – the #[test] attribute and cargo test takes care of that. This is in contrast with some other popular systems languages (notably C and C++, for example), where there is no (single) standard/de facto build system, let alone testing framework, so you have to import external libraries in order to have testing at all.

As for writing a GUI in order to check which tests to run – I would say that's pretty niche and I wouldn't expect any particular support for that in any testing environment.

As far as I can tell, the problem with testing is usually not a technical one (i.e. "the test framework is insufficiently sophisticated or lacking in features"); it's the willingness of people to sit down and write tests. (You clearly passed that bar, so this is nothing against you! Just a general observation.) For encouraging that, the most important thing is to make it easier for people to create and run tests, which apparently was/is the priority in Rust.

Re @kornel's suggestion of using macros: some people have already used macros for creating pretty sophisticated testing code, e.g. quickcheck.

3 Likes

Just saw a tweet announcing this, I don't know anything about it other than what's written, but it seems nice.

Edit: it seems like it can report test coverage information on Windows without much fiddling, which in itself is quite nice, and it runs much faster than tarpaulin.

3 Likes

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.