307 lines
17 KiB
HTML
307 lines
17 KiB
HTML
<!DOCTYPE html>
|
||
<html lang="en">
|
||
<head>
|
||
<meta charset="UTF-8">
|
||
<title>Test Organization</title>
|
||
</head>
|
||
<body>
|
||
<h2 id="test-organization"><a class="header" href="#test-organization">Test Organization</a></h2>
|
||
<p>As mentioned at the start of the chapter, testing is a complex discipline, and
|
||
different people use different terminology and organization. The Rust community
|
||
thinks about tests in terms of two main categories: unit tests and integration
|
||
tests. <em>Unit tests</em> are small and more focused, testing one module in isolation
|
||
at a time, and can test private interfaces. <em>Integration tests</em> are entirely
|
||
external to your library and use your code in the same way any other external
|
||
code would, using only the public interface and potentially exercising multiple
|
||
modules per test.</p>
|
||
<p>Writing both kinds of tests is important to ensure that the pieces of your
|
||
library are doing what you expect them to, separately and together.</p>
|
||
<h3 id="unit-tests"><a class="header" href="#unit-tests">Unit Tests</a></h3>
|
||
<p>The purpose of unit tests is to test each unit of code in isolation from the
|
||
rest of the code to quickly pinpoint where code is and isn’t working as
|
||
expected. You’ll put unit tests in the <em>src</em> directory in each file with the
|
||
code that they’re testing. The convention is to create a module named <code>tests</code>
|
||
in each file to contain the test functions and to annotate the module with
|
||
<code>cfg(test)</code>.</p>
|
||
<h4 id="the-tests-module-and-cfgtest"><a class="header" href="#the-tests-module-and-cfgtest">The <code>tests</code> Module and <code>#[cfg(test)]</code></a></h4>
|
||
<p>The <code>#[cfg(test)]</code> annotation on the <code>tests</code> module tells Rust to compile and
|
||
run the test code only when you run <code>cargo test</code>, not when you run <code>cargo build</code>. This saves compile time when you only want to build the library and
|
||
saves space in the resultant compiled artifact because the tests are not
|
||
included. You’ll see that because integration tests go in a different
|
||
directory, they don’t need the <code>#[cfg(test)]</code> annotation. However, because unit
|
||
tests go in the same files as the code, you’ll use <code>#[cfg(test)]</code> to specify
|
||
that they shouldn’t be included in the compiled result.</p>
|
||
<p>Recall that when we generated the new <code>adder</code> project in the first section of
|
||
this chapter, Cargo generated this code for us:</p>
|
||
<p><span class="filename">Filename: src/lib.rs</span></p>
|
||
<pre><code class="language-rust noplayground">pub fn add(left: u64, right: u64) -> u64 {
|
||
left + right
|
||
}
|
||
|
||
#[cfg(test)]
|
||
mod tests {
|
||
use super::*;
|
||
|
||
#[test]
|
||
fn it_works() {
|
||
let result = add(2, 2);
|
||
assert_eq!(result, 4);
|
||
}
|
||
}</code></pre>
|
||
<p>On the automatically generated <code>tests</code> module, the attribute <code>cfg</code> stands for
|
||
<em>configuration</em> and tells Rust that the following item should only be included
|
||
given a certain configuration option. In this case, the configuration option is
|
||
<code>test</code>, which is provided by Rust for compiling and running tests. By using the
|
||
<code>cfg</code> attribute, Cargo compiles our test code only if we actively run the tests
|
||
with <code>cargo test</code>. This includes any helper functions that might be within this
|
||
module, in addition to the functions annotated with <code>#[test]</code>.</p>
|
||
<!-- Old headings. Do not remove or links may break. -->
|
||
<p><a id="testing-private-functions"></a></p>
|
||
<h4 id="private-function-tests"><a class="header" href="#private-function-tests">Private Function Tests</a></h4>
|
||
<p>There’s debate within the testing community about whether or not private
|
||
functions should be tested directly, and other languages make it difficult or
|
||
impossible to test private functions. Regardless of which testing ideology you
|
||
adhere to, Rust’s privacy rules do allow you to test private functions.
|
||
Consider the code in Listing 11-12 with the private function <code>internal_adder</code>.</p>
|
||
<figure class="listing" id="listing-11-12">
|
||
<span class="file-name">Filename: src/lib.rs</span>
|
||
<pre><code class="language-rust noplayground">pub fn add_two(a: u64) -> u64 {
|
||
internal_adder(a, 2)
|
||
}
|
||
|
||
fn internal_adder(left: u64, right: u64) -> u64 {
|
||
left + right
|
||
}
|
||
|
||
#[cfg(test)]
|
||
mod tests {
|
||
use super::*;
|
||
|
||
#[test]
|
||
fn internal() {
|
||
let result = internal_adder(2, 2);
|
||
assert_eq!(result, 4);
|
||
}
|
||
}</code></pre>
|
||
<figcaption><a href="#listing-11-12">Listing 11-12</a>: Testing a private function</figcaption>
|
||
</figure>
|
||
<p>Note that the <code>internal_adder</code> function is not marked as <code>pub</code>. Tests are just
|
||
Rust code, and the <code>tests</code> module is just another module. As we discussed in
|
||
<a href="../ch07/ch07-03-paths-for-referring-to-an-item-in-the-module-tree.html">“Paths for Referring to an Item in the Module Tree”</a><!-- ignore -->,
|
||
items in child modules can use the items in their ancestor modules. In this
|
||
test, we bring all of the items belonging to the <code>tests</code> module’s parent into
|
||
scope with <code>use super::*</code>, and then the test can call <code>internal_adder</code>. If you
|
||
don’t think private functions should be tested, there’s nothing in Rust that
|
||
will compel you to do so.</p>
|
||
<h3 id="integration-tests"><a class="header" href="#integration-tests">Integration Tests</a></h3>
|
||
<p>In Rust, integration tests are entirely external to your library. They use your
|
||
library in the same way any other code would, which means they can only call
|
||
functions that are part of your library’s public API. Their purpose is to test
|
||
whether many parts of your library work together correctly. Units of code that
|
||
work correctly on their own could have problems when integrated, so test
|
||
coverage of the integrated code is important as well. To create integration
|
||
tests, you first need a <em>tests</em> directory.</p>
|
||
<h4 id="the-tests-directory"><a class="header" href="#the-tests-directory">The <em>tests</em> Directory</a></h4>
|
||
<p>We create a <em>tests</em> directory at the top level of our project directory, next
|
||
to <em>src</em>. Cargo knows to look for integration test files in this directory. We
|
||
can then make as many test files as we want, and Cargo will compile each of the
|
||
files as an individual crate.</p>
|
||
<p>Let’s create an integration test. With the code in Listing 11-12 still in the
|
||
<em>src/lib.rs</em> file, make a <em>tests</em> directory, and create a new file named
|
||
<em>tests/integration_test.rs</em>. Your directory structure should look like this:</p>
|
||
<pre><code class="language-text">adder
|
||
├── Cargo.lock
|
||
├── Cargo.toml
|
||
├── src
|
||
│ └── lib.rs
|
||
└── tests
|
||
└── integration_test.rs
|
||
</code></pre>
|
||
<p>Enter the code in Listing 11-13 into the <em>tests/integration_test.rs</em> file.</p>
|
||
<figure class="listing" id="listing-11-13">
|
||
<span class="file-name">Filename: tests/integration_test.rs</span>
|
||
<pre><code class="language-rust ignore">use adder::add_two;
|
||
|
||
#[test]
|
||
fn it_adds_two() {
|
||
let result = add_two(2);
|
||
assert_eq!(result, 4);
|
||
}</code></pre>
|
||
<figcaption><a href="#listing-11-13">Listing 11-13</a>: An integration test of a function in the <code>adder</code> crate</figcaption>
|
||
</figure>
|
||
<p>Each file in the <em>tests</em> directory is a separate crate, so we need to bring our
|
||
library into each test crate’s scope. For that reason, we add <code>use adder::add_two;</code> at the top of the code, which we didn’t need in the unit tests.</p>
|
||
<p>We don’t need to annotate any code in <em>tests/integration_test.rs</em> with
|
||
<code>#[cfg(test)]</code>. Cargo treats the <em>tests</em> directory specially and compiles files
|
||
in this directory only when we run <code>cargo test</code>. Run <code>cargo test</code> now:</p>
|
||
<pre><code class="language-console">$ cargo test
|
||
Compiling adder v0.1.0 (file:///projects/adder)
|
||
Finished `test` profile [unoptimized + debuginfo] target(s) in 1.31s
|
||
Running unittests src/lib.rs (target/debug/deps/adder-1082c4b063a8fbe6)
|
||
|
||
running 1 test
|
||
test tests::internal ... ok
|
||
|
||
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
|
||
|
||
Running tests/integration_test.rs (target/debug/deps/integration_test-1082c4b063a8fbe6)
|
||
|
||
running 1 test
|
||
test it_adds_two ... ok
|
||
|
||
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
|
||
|
||
Doc-tests adder
|
||
|
||
running 0 tests
|
||
|
||
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
|
||
|
||
</code></pre>
|
||
<p>The three sections of output include the unit tests, the integration test, and
|
||
the doc tests. Note that if any test in a section fails, the following sections
|
||
will not be run. For example, if a unit test fails, there won’t be any output
|
||
for integration and doc tests, because those tests will only be run if all unit
|
||
tests are passing.</p>
|
||
<p>The first section for the unit tests is the same as we’ve been seeing: one line
|
||
for each unit test (one named <code>internal</code> that we added in Listing 11-12) and
|
||
then a summary line for the unit tests.</p>
|
||
<p>The integration tests section starts with the line <code>Running tests/integration_test.rs</code>. Next, there is a line for each test function in
|
||
that integration test and a summary line for the results of the integration
|
||
test just before the <code>Doc-tests adder</code> section starts.</p>
|
||
<p>Each integration test file has its own section, so if we add more files in the
|
||
<em>tests</em> directory, there will be more integration test sections.</p>
|
||
<p>We can still run a particular integration test function by specifying the test
|
||
function’s name as an argument to <code>cargo test</code>. To run all the tests in a
|
||
particular integration test file, use the <code>--test</code> argument of <code>cargo test</code>
|
||
followed by the name of the file:</p>
|
||
<pre><code class="language-console">$ cargo test --test integration_test
|
||
Compiling adder v0.1.0 (file:///projects/adder)
|
||
Finished `test` profile [unoptimized + debuginfo] target(s) in 0.64s
|
||
Running tests/integration_test.rs (target/debug/deps/integration_test-82e7799c1bc62298)
|
||
|
||
running 1 test
|
||
test it_adds_two ... ok
|
||
|
||
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
|
||
|
||
</code></pre>
|
||
<p>This command runs only the tests in the <em>tests/integration_test.rs</em> file.</p>
|
||
<h4 id="submodules-in-integration-tests"><a class="header" href="#submodules-in-integration-tests">Submodules in Integration Tests</a></h4>
|
||
<p>As you add more integration tests, you might want to make more files in the
|
||
<em>tests</em> directory to help organize them; for example, you can group the test
|
||
functions by the functionality they’re testing. As mentioned earlier, each file
|
||
in the <em>tests</em> directory is compiled as its own separate crate, which is useful
|
||
for creating separate scopes to more closely imitate the way end users will be
|
||
using your crate. However, this means files in the <em>tests</em> directory don’t
|
||
share the same behavior as files in <em>src</em> do, as you learned in Chapter 7
|
||
regarding how to separate code into modules and files.</p>
|
||
<p>The different behavior of <em>tests</em> directory files is most noticeable when you
|
||
have a set of helper functions to use in multiple integration test files, and
|
||
you try to follow the steps in the <a href="../ch07/ch07-05-separating-modules-into-different-files.html">“Separating Modules into Different
|
||
Files”</a><!-- ignore --> section of Chapter 7 to
|
||
extract them into a common module. For example, if we create <em>tests/common.rs</em>
|
||
and place a function named <code>setup</code> in it, we can add some code to <code>setup</code> that
|
||
we want to call from multiple test functions in multiple test files:</p>
|
||
<p><span class="filename">Filename: tests/common.rs</span></p>
|
||
<pre><code class="language-rust noplayground">pub fn setup() {
|
||
// setup code specific to your library's tests would go here
|
||
}</code></pre>
|
||
<p>When we run the tests again, we’ll see a new section in the test output for the
|
||
<em>common.rs</em> file, even though this file doesn’t contain any test functions nor
|
||
did we call the <code>setup</code> function from anywhere:</p>
|
||
<pre><code class="language-console">$ cargo test
|
||
Compiling adder v0.1.0 (file:///projects/adder)
|
||
Finished `test` profile [unoptimized + debuginfo] target(s) in 0.89s
|
||
Running unittests src/lib.rs (target/debug/deps/adder-92948b65e88960b4)
|
||
|
||
running 1 test
|
||
test tests::internal ... ok
|
||
|
||
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
|
||
|
||
Running tests/common.rs (target/debug/deps/common-92948b65e88960b4)
|
||
|
||
running 0 tests
|
||
|
||
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
|
||
|
||
Running tests/integration_test.rs (target/debug/deps/integration_test-92948b65e88960b4)
|
||
|
||
running 1 test
|
||
test it_adds_two ... ok
|
||
|
||
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
|
||
|
||
Doc-tests adder
|
||
|
||
running 0 tests
|
||
|
||
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
|
||
|
||
</code></pre>
|
||
<p>Having <code>common</code> appear in the test results with <code>running 0 tests</code> displayed for
|
||
it is not what we wanted. We just wanted to share some code with the other
|
||
integration test files. To avoid having <code>common</code> appear in the test output,
|
||
instead of creating <em>tests/common.rs</em>, we’ll create <em>tests/common/mod.rs</em>. The
|
||
project directory now looks like this:</p>
|
||
<pre><code class="language-text">├── Cargo.lock
|
||
├── Cargo.toml
|
||
├── src
|
||
│ └── lib.rs
|
||
└── tests
|
||
├── common
|
||
│ └── mod.rs
|
||
└── integration_test.rs
|
||
</code></pre>
|
||
<p>This is the older naming convention that Rust also understands that we mentioned
|
||
in <a href="../ch07/ch07-05-separating-modules-into-different-files.html#alternate-file-paths">“Alternate File Paths”</a><!-- ignore --> in Chapter 7. Naming the
|
||
file this way tells Rust not to treat the <code>common</code> module as an integration test
|
||
file. When we move the <code>setup</code> function code into <em>tests/common/mod.rs</em> and
|
||
delete the <em>tests/common.rs</em> file, the section in the test output will no longer
|
||
appear. Files in subdirectories of the <em>tests</em> directory don’t get compiled as
|
||
separate crates or have sections in the test output.</p>
|
||
<p>After we’ve created <em>tests/common/mod.rs</em>, we can use it from any of the
|
||
integration test files as a module. Here’s an example of calling the <code>setup</code>
|
||
function from the <code>it_adds_two</code> test in <em>tests/integration_test.rs</em>:</p>
|
||
<p><span class="filename">Filename: tests/integration_test.rs</span></p>
|
||
<pre><code class="language-rust ignore">use adder::add_two;
|
||
|
||
mod common;
|
||
|
||
#[test]
|
||
fn it_adds_two() {
|
||
common::setup();
|
||
|
||
let result = add_two(2);
|
||
assert_eq!(result, 4);
|
||
}</code></pre>
|
||
<p>Note that the <code>mod common;</code> declaration is the same as the module declaration
|
||
we demonstrated in Listing 7-21. Then, in the test function, we can call the
|
||
<code>common::setup()</code> function.</p>
|
||
<h4 id="integration-tests-for-binary-crates"><a class="header" href="#integration-tests-for-binary-crates">Integration Tests for Binary Crates</a></h4>
|
||
<p>If our project is a binary crate that only contains a <em>src/main.rs</em> file and
|
||
doesn’t have a <em>src/lib.rs</em> file, we can’t create integration tests in the
|
||
<em>tests</em> directory and bring functions defined in the <em>src/main.rs</em> file into
|
||
scope with a <code>use</code> statement. Only library crates expose functions that other
|
||
crates can use; binary crates are meant to be run on their own.</p>
|
||
<p>This is one of the reasons Rust projects that provide a binary have a
|
||
straightforward <em>src/main.rs</em> file that calls logic that lives in the
|
||
<em>src/lib.rs</em> file. Using that structure, integration tests <em>can</em> test the
|
||
library crate with <code>use</code> to make the important functionality available. If the
|
||
important functionality works, the small amount of code in the <em>src/main.rs</em>
|
||
file will work as well, and that small amount of code doesn’t need to be tested.</p>
|
||
<h2 id="summary"><a class="header" href="#summary">Summary</a></h2>
|
||
<p>Rust’s testing features provide a way to specify how code should function to
|
||
ensure that it continues to work as you expect, even as you make changes. Unit
|
||
tests exercise different parts of a library separately and can test private
|
||
implementation details. Integration tests check that many parts of the library
|
||
work together correctly, and they use the library’s public API to test the code
|
||
in the same way external code will use it. Even though Rust’s type system and
|
||
ownership rules help prevent some kinds of bugs, tests are still important to
|
||
reduce logic bugs having to do with how your code is expected to behave.</p>
|
||
<p>Let’s combine the knowledge you learned in this chapter and in previous
|
||
chapters to work on a project!</p>
|
||
</body>
|
||
</html>
|