
The internals of testing in Rust in 2018 - djrenren
http://blog.jrenner.net/rust/testing/2018/07/19/test-in-2018.html
======
cornstalks
Looking 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)

~~~
djrenren
Hi 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.

~~~
hinkley
There'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).

~~~
djrenren
I don't believe this would work with the rustc compiler because, although it
uses Cargo to build, it has a special process that bootstraps the compiler by
building itself.

------
nixpulvis
The accessibility of testing code in Rust is one of the best parts of the
tooling IMO.

~~~
jordigh
I 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
Rust 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`.

------
majewsky
Doc 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.

~~~
djrenren
Yeah, 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...](https://github.com/rust-
lang/rust/blob/master/src/librustdoc/test.rs)

