Add testing chapter
This commit is contained in:
parent
0298cedcfa
commit
c13c5a019f
|
|
@ -17,6 +17,7 @@
|
||||||
- [Incremental compilation](./incremental-compilation.md)
|
- [Incremental compilation](./incremental-compilation.md)
|
||||||
- [Debugging and Testing](./incrcomp-debugging.md)
|
- [Debugging and Testing](./incrcomp-debugging.md)
|
||||||
- [The parser](./the-parser.md)
|
- [The parser](./the-parser.md)
|
||||||
|
- [Testing](./testing.md)
|
||||||
- [Macro expansion](./macro-expansion.md)
|
- [Macro expansion](./macro-expansion.md)
|
||||||
- [Name resolution](./name-resolution.md)
|
- [Name resolution](./name-resolution.md)
|
||||||
- [The HIR (High-level IR)](./hir.md)
|
- [The HIR (High-level IR)](./hir.md)
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,145 @@
|
||||||
|
### The `#[test]` attribute
|
||||||
|
Today, rust programmers rely on a built in attribute called `#[test]`.
|
||||||
|
All you have to do is mark a function as a test and include some asserts like so:
|
||||||
|
|
||||||
|
```rust,ignore
|
||||||
|
#[test]
|
||||||
|
fn my_test() {
|
||||||
|
assert!(2+2 == 4);
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
When this program is compiled using `rustc --test` or `cargo test`, it will
|
||||||
|
produce an executable that can run this, and any other test function. This
|
||||||
|
method of testing allows tests to live alongside code in an organic way. You
|
||||||
|
can even put tests inside private modules:
|
||||||
|
|
||||||
|
```rust,ignore
|
||||||
|
mod my_priv_mod {
|
||||||
|
fn my_priv_func() -> bool {}
|
||||||
|
|
||||||
|
#[test]
|
||||||
|
fn test_priv_func() {
|
||||||
|
assert!(my_priv_func());
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
Private items can thus be easily tested without worrying about how to expose
|
||||||
|
the them to any sort of external testing apparatus. This is key to the
|
||||||
|
ergonomics of testing in Rust. Semantically, however, it's rather odd.
|
||||||
|
How does any sort of `main` function invoke these tests if they're not visible?
|
||||||
|
What exactly is `rustc --test` doing?
|
||||||
|
|
||||||
|
`#[test]` is implemented as a syntactic transformation inside the compiler's
|
||||||
|
[`libsyntax` crate][libsyntax]. Essentially, it's a fancy macro, that
|
||||||
|
rewrites the crate in 3 steps:
|
||||||
|
|
||||||
|
#### Step 1: Re-Exporting
|
||||||
|
|
||||||
|
As mentioned earlier, tests can exist inside private modules, so we need a way of
|
||||||
|
exposing them to the main function, without breaking any existing code. To that end,
|
||||||
|
`libsyntax` will create local modules called `__test_reexports` that recursively reexport tests.
|
||||||
|
This expansion translates the above example into:
|
||||||
|
|
||||||
|
```rust,ignore
|
||||||
|
mod my_priv_mod {
|
||||||
|
fn my_priv_func() -> bool {}
|
||||||
|
|
||||||
|
pub fn test_priv_func() {
|
||||||
|
assert!(my_priv_func());
|
||||||
|
}
|
||||||
|
|
||||||
|
pub mod __test_reexports {
|
||||||
|
pub use super::test_priv_func;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Now, our test can be accessed as
|
||||||
|
`my_priv_mod::__test_reexports::test_priv_func`. For deeper module
|
||||||
|
structures, `__test_reexports` will reexport modules that contain tests, so a
|
||||||
|
test at `a::b::my_test` becomes
|
||||||
|
`a::__test_reexports::b::__test_reexports::my_test`. While this process seems
|
||||||
|
pretty safe, what happens if there is an existing `__test_reexports` module?
|
||||||
|
The answer: nothing.
|
||||||
|
|
||||||
|
To explain, we need to understand [how the AST represents
|
||||||
|
identifiers][Ident]. The name of every function, variable, module, etc. is
|
||||||
|
not stored as a string, but rather as an opaque [Symbol][Symbol] which is
|
||||||
|
essentially an ID number for each identifier. The compiler keeps a separate
|
||||||
|
hashtable that allows us to recover the human-readable name of a Symbol when
|
||||||
|
necessary (such as when printing a syntax error). When the compiler generates
|
||||||
|
the `__test_reexports` module, it generates a new Symbol for the identifier,
|
||||||
|
so while the compiler-generated `__test_reexports` may share a name with your
|
||||||
|
hand-written one, it will not share a Symbol. This technique prevents name
|
||||||
|
collision during code generation and is the foundation of Rust's macro
|
||||||
|
hygiene.
|
||||||
|
|
||||||
|
#### Step 2: Harness Generation
|
||||||
|
Now that our tests are accessible from the root of our crate, we need to do something with them.
|
||||||
|
`libsyntax` generates a module like so:
|
||||||
|
|
||||||
|
```rust,ignore
|
||||||
|
pub mod __test {
|
||||||
|
extern crate test;
|
||||||
|
const TESTS: &'static [self::test::TestDescAndFn] = &[/*...*/];
|
||||||
|
|
||||||
|
#[main]
|
||||||
|
pub fn main() {
|
||||||
|
self::test::test_static_main(TESTS);
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
While this transformation is simple, it gives us a lot of insight into how tests are actually run.
|
||||||
|
The tests are aggregated into an array and passed to a test runner called `test_static_main`.
|
||||||
|
We'll come back to exactly what `TestDescAndFn` is, but for now, the key takeaway is that there is a crate
|
||||||
|
called [`test`][test] that is part of Rust core, that implements all of the runtime for testing. `test`'s interface is unstable,
|
||||||
|
so the only stable way to interact with it is through the `#[test]` macro.
|
||||||
|
|
||||||
|
#### Step 3: Test Object Generation
|
||||||
|
If you've written tests in Rust before, you may be familiar with some of the optional attributes available on test functions.
|
||||||
|
For example, a test can be annotated with `#[should_panic]` if we expect the test to cause a panic. It looks something like this:
|
||||||
|
|
||||||
|
```rust,ignore
|
||||||
|
#[test]
|
||||||
|
#[should_panic]
|
||||||
|
fn foo() {
|
||||||
|
panic!("intentional");
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
This means our tests are more than just simple functions, they have configuration information as well. `test` encodes this configuration
|
||||||
|
data into a struct called [`TestDesc`][TestDesc]. For each test function in a crate, `libsyntax` will parse its attributes and generate a `TestDesc` instance.
|
||||||
|
It then combines the `TestDesc` and test function into the predictably named `TestDescAndFn` struct, that `test_static_main` operates on.
|
||||||
|
For a given test, the generated `TestDescAndFn` instance looks like so:
|
||||||
|
|
||||||
|
```rust,ignore
|
||||||
|
self::test::TestDescAndFn{
|
||||||
|
desc: self::test::TestDesc{
|
||||||
|
name: self::test::StaticTestName("foo"),
|
||||||
|
ignore: false,
|
||||||
|
should_panic: self::test::ShouldPanic::Yes,
|
||||||
|
allow_fail: false,
|
||||||
|
},
|
||||||
|
testfn: self::test::StaticTestFn(||
|
||||||
|
self::test::assert_test_result(::crate::__test_reexports::foo())),
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Once we've constructed an array of these test objects, they're passed to the
|
||||||
|
test runner via the harness generated in step 2.
|
||||||
|
|
||||||
|
### Inspecting the generated code
|
||||||
|
On nightly rust, there's an unstable flag called `unpretty` that you can use to print out the module source after macro expansion:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
$ rustc my_mod.rs -Z unpretty=hir
|
||||||
|
```
|
||||||
|
|
||||||
|
[test]: https://doc.rust-lang.org/test/index.html
|
||||||
|
[TestDesc]: https://doc.rust-lang.org/test/struct.TestDesc.html
|
||||||
|
[Symbol]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Ident.html
|
||||||
|
[Ident]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Ident.html
|
||||||
|
[eRFC]: https://github.com/rust-lang/rfcs/blob/master/text/2318-custom-test-frameworks.md
|
||||||
|
[libsyntax]: https://github.com/rust-lang/rust/tree/master/src/libsyntax
|
||||||
Loading…
Reference in New Issue