8 ms·
The internals of testing in Rust in 2018
- nixpulvis 8y agoThe accessibility of testing code in Rust is one of the best parts of the tooling IMO.
- jordigh 8y agoI find this pretty nice in D. You add unittest{} blocks which you compile into or out of your binary with a compiler flag. If you add some appropriately formatted comments, ddoc also turns those into docstrings with the test as example usage. https://dlang.org/spec/unittest.html https://dlang.org/spec/unittest.html
- skolemtotem 8y agoRust takes a similar approach. For unit tests, you use the #[cfg(test)] attribute (/ pragma / directive) for conditional compilation, and #[test] to mark a function that is a unit test, which is run whenever you run the `cargo test` command. Also, any Rust code in Markdown fences in documentation is, by default, also run by `cargo test`, which you can disable for an individual code block by marking it as `rust,norun` instead of `rust`.
- mlindner 8y agoI've seen two different posts come on to this thread to comment about D. It makes me wonder what's going on if they need come in and say 'But wait D is good too!' whenever Rust is talked about.
- erichdongubler 8y agoShameless plug: you can have D-ish testing blocks with a macro I published on https://crates.io https://crates.io as `adhesion`: https://github.com/erichdongubler/adhesion-rs https://github.com/erichdongubler/adhesion-rs
- cornstalks 8y agoLooking at this, I can now see why a test function nested in another function (see [0] and [1]) doesn’t work. I’ve tried dabbling with the Rust compiler to see if I could help fix this, but it takes 30 minutes to compile rustc and I couldn’t figure out how to reduce those compile times (each time I changed 1 line and wanted to test, I had to wait 30 minutes to build). How do people work on rustc (or internal Rust libraries, like libsyntax) without waiting for 30 minute builds after every minor change? [0]: https://github.com/rust-lang/rust/issues/36629 https://github.com/rust-lang/rust/issues/36629 [1]: https://github.com/rust-lang/rfcs/issues/612 https://github.com/rust-lang/rfcs/issues/612
- estebank 8y ago./x.py test src/test/ui --stage 1 And coffee, as that already takes around 5 to 20 minutes depending on what part of the compiler you're touching.
- djrenren 8y agoHi author here, I won't lie, it's rough. I definitely built this whole website and wrote the blog during my "compile breaks". On the bright side, typechecking is super fast so I only really have to wait when making algorithmic changes. Still, especially for anything that does code generation, you'll be tweaking the algorithm a good deal.
- antpls 8y agoWould building the compiler on cloud instances help? If the compiler is built in Rust, I guess it would efficiently use several dozens of cores and gigabytes of RAM
- hinkley 8y agoThere's a cargo watch command that tries to do the same thing that other languages with slow compilation or test frameworks do, and that's to run all your tests the minute you save. This narrows the time between when you have something to test and when you remember to test it. It saves you wall clock time if not CPU time. (I highly recommend combining watch with an editor or IDE that saves all buffers at the same time, instead of one at a time).
- majewsky 8y agoDoc tests are their own thing, right? When I do `cargo test`, it looks like it's doing two passes: one for unit tests (like described in the article), and one for doc tests.
- steveklabnik 8y agoThey still use this infrastructure; think of it as a specific way to construct this kind of test.
- djrenren 8y agoYeah, doc tests are part of rustdoc and they essentially strip out the comments and generate test functions using libtest. I'm not very familiar with the internals, but they're here: https://github.com/rust-lang/rust/blob/master/src/librustdoc/test.rs https://github.com/rust-lang/rust/blob/master/src/librustdoc...