Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

How's testing in Rust compared to Python?


The good part is that it's built-in, and tests can be "whitebox" (inside the file they're testing and with access to everything) and "blackbox" (outside of the crate, and with only access to public APIs). They're also multithreaded by default, the reporting is OK, doctests of doc-comments are on and enabled by default. So the OOTB experience is mostly better than Python's unittest I think (though the reporting is not as good as it's missing the slew of dedicated methods and corresponding precise reporting).

Rust's rules also make some of the complexities... not entirely necessary e.g. an object with a Drop can stand in for a setup/teardown quite nicely, thus standard packages like tempfile obviate the need for specific support.

However it's nowhere near the comfort of a pytest: while Rust doesn't have more overhead (a test function is just a function with a `#[test]` annotation)

- the missing scopes above "test" can be dear (especially because pseudo-globals like lazy_static and once_cell don't get dropped so there's no real teardown at the session level), though obviously some is understandable due to tests being multithreaded-by-default

- rust test-support-types are more verbose than fixtures

- the reporting is nowhere as precise as pytest's assertion rewriting

- the lack of parametric testing is annoying for reporting and addressing perspectives: "hand-rolled" table-based testing is OK, but the lack of subtests makes reporting less than ideal, and the inability to (re)run just one of the parametric tests can be frustrating

- it's missing a lot of the nice CLI options of pytest, especially about test-sets and run caches: marks, but also stepwise, exitfirst, last-failed, failed-first, new-first

The type system does compensate, to an extent, as it limits the test-space. Tremendously so if you purposefully encode your invariants in types.


> They're also multithreaded by default, the reporting is OK, doctests of doc-comments are on and enabled by default

A caveat here - doctests end up compiled into a separate binary for every test. I tried turning my unit tests into doctests, because they felt more natural there, but test iteration time went from 0.02 seconds to 14 seconds :(


Much much better. Mostly because you have to write about 1/10th the number of tests to get the same level of assurance.

Also there's a standard command for running tests in Rust but not Python.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: