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 :
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?
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.
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.
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.
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.