496 lines
40 KiB
HTML
496 lines
40 KiB
HTML
|
<!DOCTYPE HTML>
|
|||
|
|
<html lang="en" class="sidebar-visible no-js light">
|
|||
|
|
<head>
|
|||
|
|
<!-- Book generated using mdBook -->
|
|||
|
|
<meta charset="UTF-8">
|
|||
|
|
<title>Test Organization - The Rust Programming Language</title>
|
|||
|
|
|
|||
|
|
|
|||
|
|
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
|
|||
|
|
<meta name="description" content="">
|
|||
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|||
|
|
<meta name="theme-color" content="#ffffff" />
|
|||
|
|
|
|||
|
|
<link rel="shortcut icon" href="favicon.png">
|
|||
|
|
<link rel="stylesheet" href="css/variables.css">
|
|||
|
|
<link rel="stylesheet" href="css/general.css">
|
|||
|
|
<link rel="stylesheet" href="css/chrome.css">
|
|||
|
|
<link rel="stylesheet" href="css/print.css" media="print">
|
|||
|
|
|
|||
|
|
<!-- Fonts -->
|
|||
|
|
<link rel="stylesheet" href="FontAwesome/css/font-awesome.css">
|
|||
|
|
<link href="googleFonts/css.css" rel="stylesheet" type="text/css">
|
|||
|
|
|
|||
|
|
<!-- Highlight.js Stylesheets -->
|
|||
|
|
<link rel="stylesheet" href="highlight.css">
|
|||
|
|
<link rel="stylesheet" href="tomorrow-night.css">
|
|||
|
|
<link rel="stylesheet" href="ayu-highlight.css">
|
|||
|
|
|
|||
|
|
<!-- Custom theme stylesheets -->
|
|||
|
|
|
|||
|
|
<link rel="stylesheet" href="ferris.css">
|
|||
|
|
|
|||
|
|
<link rel="stylesheet" href="theme/2018-edition.css">
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
</head>
|
|||
|
|
<body>
|
|||
|
|
<!-- Provide site root to javascript -->
|
|||
|
|
<script type="text/javascript">
|
|||
|
|
var path_to_root = "";
|
|||
|
|
var default_theme = window.matchMedia("(prefers-color-scheme: dark)").matches ? "light" : "light";
|
|||
|
|
</script>
|
|||
|
|
|
|||
|
|
<!-- Work around some values being stored in localStorage wrapped in quotes -->
|
|||
|
|
<script type="text/javascript">
|
|||
|
|
try {
|
|||
|
|
var theme = localStorage.getItem('mdbook-theme');
|
|||
|
|
var sidebar = localStorage.getItem('mdbook-sidebar');
|
|||
|
|
|
|||
|
|
if (theme.startsWith('"') && theme.endsWith('"')) {
|
|||
|
|
localStorage.setItem('mdbook-theme', theme.slice(1, theme.length - 1));
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
if (sidebar.startsWith('"') && sidebar.endsWith('"')) {
|
|||
|
|
localStorage.setItem('mdbook-sidebar', sidebar.slice(1, sidebar.length - 1));
|
|||
|
|
}
|
|||
|
|
} catch (e) { }
|
|||
|
|
</script>
|
|||
|
|
|
|||
|
|
<!-- Set the theme before any content is loaded, prevents flash -->
|
|||
|
|
<script type="text/javascript">
|
|||
|
|
var theme;
|
|||
|
|
try { theme = localStorage.getItem('mdbook-theme'); } catch(e) { }
|
|||
|
|
if (theme === null || theme === undefined) { theme = default_theme; }
|
|||
|
|
var html = document.querySelector('html');
|
|||
|
|
html.classList.remove('no-js')
|
|||
|
|
html.classList.remove('light')
|
|||
|
|
html.classList.add(theme);
|
|||
|
|
html.classList.add('js');
|
|||
|
|
</script>
|
|||
|
|
|
|||
|
|
<!-- Hide / unhide sidebar before it is displayed -->
|
|||
|
|
<script type="text/javascript">
|
|||
|
|
var html = document.querySelector('html');
|
|||
|
|
var sidebar = 'hidden';
|
|||
|
|
if (document.body.clientWidth >= 1080) {
|
|||
|
|
try { sidebar = localStorage.getItem('mdbook-sidebar'); } catch(e) { }
|
|||
|
|
sidebar = sidebar || 'visible';
|
|||
|
|
}
|
|||
|
|
html.classList.remove('sidebar-visible');
|
|||
|
|
html.classList.add("sidebar-" + sidebar);
|
|||
|
|
</script>
|
|||
|
|
|
|||
|
|
<nav id="sidebar" class="sidebar" aria-label="Table of contents">
|
|||
|
|
<div id="sidebar-scrollbox" class="sidebar-scrollbox">
|
|||
|
|
<ol class="chapter"><li class="expanded affix "><a href="title-page.html">The Rust Programming Language</a></li><li class="expanded affix "><a href="foreword.html">Foreword</a></li><li class="expanded affix "><a href="ch00-00-introduction.html">Introduction</a></li><li class="expanded "><a href="ch01-00-getting-started.html"><strong aria-hidden="true">1.</strong> Getting Started</a></li><li><ol class="section"><li class="expanded "><a href="ch01-01-installation.html"><strong aria-hidden="true">1.1.</strong> Installation</a></li><li class="expanded "><a href="ch01-02-hello-world.html"><strong aria-hidden="true">1.2.</strong> Hello, World!</a></li><li class="expanded "><a href="ch01-03-hello-cargo.html"><strong aria-hidden="true">1.3.</strong> Hello, Cargo!</a></li></ol></li><li class="expanded "><a href="ch02-00-guessing-game-tutorial.html"><strong aria-hidden="true">2.</strong> Programming a Guessing Game</a></li><li class="expanded "><a href="ch03-00-common-programming-concepts.html"><strong aria-hidden="true">3.</strong> Common Programming Concepts</a></li><li><ol class="section"><li class="expanded "><a href="ch03-01-variables-and-mutability.html"><strong aria-hidden="true">3.1.</strong> Variables and Mutability</a></li><li class="expanded "><a href="ch03-02-data-types.html"><strong aria-hidden="true">3.2.</strong> Data Types</a></li><li class="expanded "><a href="ch03-03-how-functions-work.html"><strong aria-hidden="true">3.3.</strong> Functions</a></li><li class="expanded "><a href="ch03-04-comments.html"><strong aria-hidden="true">3.4.</strong> Comments</a></li><li class="expanded "><a href="ch03-05-control-flow.html"><strong aria-hidden="true">3.5.</strong> Control Flow</a></li></ol></li><li class="expanded "><a href="ch04-00-understanding-ownership.html"><strong aria-hidden="true">4.</strong> Understanding Ownership</a></li><li><ol class="section"><li class="expanded "><a href="ch04-01-what-is-ownership.html"><strong aria-hidden="true">4.1.</strong> What is Ownership?</a></li><li class="expanded "><a href="ch04-02-references-and-borrowing.html"><strong aria-hidden="true">4.2.</strong> References and Borrowing</a></li><li class="expanded "><a href="ch04-03-slices.html"><strong aria-hidden="true">4.3.</strong> The Slice Type</a></li></ol></li><li class="expanded "><a href="ch05-00-structs.html"><strong aria-hidden="true">5.</strong> Using Structs to Structure Related Data</a></li><li><ol class="section"><li class="expanded "><a href="ch05-01-defining-structs.html"><strong aria-hidden="true">5.1.</strong> Defining and Instantiating Structs</a></li><li class="expanded "><a href="ch05-02-example-structs.html"><strong aria-hidden="true">5.2.</strong> An Example Program Using Structs</a></li><li class="expanded "><a href="ch05-03-method-syntax.html"><strong aria-hidden="true">5.3.</strong> Method Syntax</a></li></ol></li><li class="expanded "><a href="ch06-00-enums.html"><strong aria-hidden="true">6.</strong> Enums and Pattern Matching</a></li><li><ol class="section"><li class="expanded "><a href="ch06-01-defining-an-enum.html"><strong aria-hidden="true">6.1.</strong> Defining an Enum</a></li><li class="expanded "><a href="ch06-02-match.html"><strong aria-hidden="true">6.2.</strong> The match Control Flow Operator</a></li><li class="expanded "><a href="ch06-03-if-let.html"><strong aria-hidden="true">6.3.</strong> Concise Control Flow with if let</a></li></ol></li><li class="expanded "><a href="ch07-00-managing-growing-projects-with-packages-crates-and-modules.html"><strong aria-hidden="true">7.</strong> Managing Growing Projects with Packages, Crates, and Modules</a></li><li><ol class="section"><li class="expanded "><a href="ch07-01-packages-and-crates.html"><strong aria-hidden="true">7.1.</strong> Packages and Crates</a></li><li class="expanded "><a href="ch07-02-defining-modules-to-control-scope-and-privacy.html"><strong aria-hidden="true">7.2.</strong> Defining Modules to Control Scope and Privacy</a></li><li class="expanded "><a href="ch07-03-paths-for-referring-to-an-item-in-the-module-tree.html"><
|
|||
|
|
</div>
|
|||
|
|
<div id="sidebar-resize-handle" class="sidebar-resize-handle"></div>
|
|||
|
|
</nav>
|
|||
|
|
|
|||
|
|
<div id="page-wrapper" class="page-wrapper">
|
|||
|
|
|
|||
|
|
<div class="page">
|
|||
|
|
|
|||
|
|
<div id="menu-bar" class="menu-bar">
|
|||
|
|
<div id="menu-bar-sticky-container">
|
|||
|
|
<div class="left-buttons">
|
|||
|
|
<button id="sidebar-toggle" class="icon-button" type="button" title="Toggle Table of Contents" aria-label="Toggle Table of Contents" aria-controls="sidebar">
|
|||
|
|
<i class="fa fa-bars"></i>
|
|||
|
|
</button>
|
|||
|
|
<button id="theme-toggle" class="icon-button" type="button" title="Change theme" aria-label="Change theme" aria-haspopup="true" aria-expanded="false" aria-controls="theme-list">
|
|||
|
|
<i class="fa fa-paint-brush"></i>
|
|||
|
|
</button>
|
|||
|
|
<ul id="theme-list" class="theme-popup" aria-label="Themes" role="menu">
|
|||
|
|
<li role="none"><button role="menuitem" class="theme" id="light">Light (default)</button></li>
|
|||
|
|
<li role="none"><button role="menuitem" class="theme" id="rust">Rust</button></li>
|
|||
|
|
<li role="none"><button role="menuitem" class="theme" id="coal">Coal</button></li>
|
|||
|
|
<li role="none"><button role="menuitem" class="theme" id="navy">Navy</button></li>
|
|||
|
|
<li role="none"><button role="menuitem" class="theme" id="ayu">Ayu</button></li>
|
|||
|
|
</ul>
|
|||
|
|
|
|||
|
|
<button id="search-toggle" class="icon-button" type="button" title="Search. (Shortkey: s)" aria-label="Toggle Searchbar" aria-expanded="false" aria-keyshortcuts="S" aria-controls="searchbar">
|
|||
|
|
<i class="fa fa-search"></i>
|
|||
|
|
</button>
|
|||
|
|
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
<h1 class="menu-title">The Rust Programming Language</h1>
|
|||
|
|
|
|||
|
|
<div class="right-buttons">
|
|||
|
|
<a href="print.html" title="Print this book" aria-label="Print this book">
|
|||
|
|
<i id="print-button" class="fa fa-print"></i>
|
|||
|
|
</a>
|
|||
|
|
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
|
|||
|
|
<div id="search-wrapper" class="hidden">
|
|||
|
|
<form id="searchbar-outer" class="searchbar-outer">
|
|||
|
|
<input type="search" name="search" id="searchbar" name="searchbar" placeholder="Search this book ..." aria-controls="searchresults-outer" aria-describedby="searchresults-header">
|
|||
|
|
</form>
|
|||
|
|
<div id="searchresults-outer" class="searchresults-outer hidden">
|
|||
|
|
<div id="searchresults-header" class="searchresults-header"></div>
|
|||
|
|
<ul id="searchresults">
|
|||
|
|
</ul>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!-- Apply ARIA attributes after the sidebar and the sidebar toggle button are added to the DOM -->
|
|||
|
|
<script type="text/javascript">
|
|||
|
|
document.getElementById('sidebar-toggle').setAttribute('aria-expanded', sidebar === 'visible');
|
|||
|
|
document.getElementById('sidebar').setAttribute('aria-hidden', sidebar !== 'visible');
|
|||
|
|
Array.from(document.querySelectorAll('#sidebar a')).forEach(function(link) {
|
|||
|
|
link.setAttribute('tabIndex', sidebar === 'visible' ? 0 : -1);
|
|||
|
|
});
|
|||
|
|
</script>
|
|||
|
|
|
|||
|
|
<div id="content" class="content">
|
|||
|
|
<main>
|
|||
|
|
<h2><a class="header" href="#test-organization" id="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: <em>unit tests</em> and
|
|||
|
|
<em>integration tests</em>. Unit tests are small and more focused, testing one module
|
|||
|
|
in isolation at a time, and can test private interfaces. Integration tests 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><a class="header" href="#unit-tests" id="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><a class="header" href="#the-tests-module-and-cfgtest" id="the-tests-module-and-cfgtest">The Tests Module and <code>#[cfg(test)]</code></a></h4>
|
|||
|
|
<p>The <code>#[cfg(test)]</code> annotation on the tests 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 resulting 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><pre class="playpen"><code class="language-rust">
|
|||
|
|
<span class="boring">#![allow(unused_variables)]
|
|||
|
|
</span><span class="boring">fn main() {
|
|||
|
|
</span>#[cfg(test)]
|
|||
|
|
mod tests {
|
|||
|
|
#[test]
|
|||
|
|
fn it_works() {
|
|||
|
|
assert_eq!(2 + 2, 4);
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
<span class="boring">}
|
|||
|
|
</span></code></pre></pre>
|
|||
|
|
<p>This code is the automatically generated test 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>
|
|||
|
|
<h4><a class="header" href="#testing-private-functions" id="testing-private-functions">Testing Private Functions</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>
|
|||
|
|
<p><span class="filename">Filename: src/lib.rs</span></p>
|
|||
|
|
<pre><pre class="playpen"><code class="language-rust"><span class="boring">fn main() {}
|
|||
|
|
</span>
|
|||
|
|
pub fn add_two(a: i32) -> i32 {
|
|||
|
|
internal_adder(a, 2)
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
fn internal_adder(a: i32, b: i32) -> i32 {
|
|||
|
|
a + b
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
#[cfg(test)]
|
|||
|
|
mod tests {
|
|||
|
|
use super::*;
|
|||
|
|
|
|||
|
|
#[test]
|
|||
|
|
fn internal() {
|
|||
|
|
assert_eq!(4, internal_adder(2, 2));
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
</code></pre></pre>
|
|||
|
|
<p><span class="caption">Listing 11-12: Testing a private function</span></p>
|
|||
|
|
<p>Note that the <code>internal_adder</code> function is not marked as <code>pub</code>, but because
|
|||
|
|
tests are just Rust code and the <code>tests</code> module is just another module, you can
|
|||
|
|
bring <code>internal_adder</code> into a test’s scope and call it. If you don’t think
|
|||
|
|
private functions should be tested, there’s nothing in Rust that will compel
|
|||
|
|
you to do so.</p>
|
|||
|
|
<h3><a class="header" href="#integration-tests" id="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><a class="header" href="#the-tests-directory" id="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 to in this directory, 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, create a new file named
|
|||
|
|
<em>tests/integration_test.rs</em>, and enter the code in Listing 11-13.</p>
|
|||
|
|
<p><span class="filename">Filename: tests/integration_test.rs</span></p>
|
|||
|
|
<pre><code class="language-rust ignore">use adder;
|
|||
|
|
|
|||
|
|
#[test]
|
|||
|
|
fn it_adds_two() {
|
|||
|
|
assert_eq!(4, adder::add_two(2));
|
|||
|
|
}
|
|||
|
|
</code></pre>
|
|||
|
|
<p><span class="caption">Listing 11-13: An integration test of a function in the
|
|||
|
|
<code>adder</code> crate</span></p>
|
|||
|
|
<p>We’ve added <code>use adder</code> at the top of the code, which we didn’t need in the
|
|||
|
|
unit tests. The reason is that each file in the <code>tests</code> directory is a separate
|
|||
|
|
crate, so we need to bring our library into each test crate’s scope.</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 <code>tests</code> 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-text">$ cargo test
|
|||
|
|
Compiling adder v0.1.0 (file:///projects/adder)
|
|||
|
|
Finished dev [unoptimized + debuginfo] target(s) in 0.31 secs
|
|||
|
|
Running target/debug/deps/adder-abcabcabc
|
|||
|
|
|
|||
|
|
running 1 test
|
|||
|
|
test tests::internal ... ok
|
|||
|
|
|
|||
|
|
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
|
|||
|
|
|
|||
|
|
Running target/debug/deps/integration_test-ce99bcc2479f4607
|
|||
|
|
|
|||
|
|
running 1 test
|
|||
|
|
test it_adds_two ... ok
|
|||
|
|
|
|||
|
|
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
|
|||
|
|
|
|||
|
|
Doc-tests adder
|
|||
|
|
|
|||
|
|
running 0 tests
|
|||
|
|
|
|||
|
|
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
|
|||
|
|
</code></pre>
|
|||
|
|
<p>The three sections of output include the unit tests, the integration test, and
|
|||
|
|
the doc tests. 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 target/debug/deps/integration_test-ce99bcc2479f4607</code> (the hash at the end of
|
|||
|
|
your output will be different). 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>Similarly to how adding more unit test functions adds more result lines to the
|
|||
|
|
unit tests section, adding more test functions to the integration test file
|
|||
|
|
adds more result lines to this integration test file’s section. 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-text">$ cargo test --test integration_test
|
|||
|
|
Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
|
|||
|
|
Running target/debug/integration_test-952a27e0126bb565
|
|||
|
|
|
|||
|
|
running 1 test
|
|||
|
|
test it_adds_two ... ok
|
|||
|
|
|
|||
|
|
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
|
|||
|
|
</code></pre>
|
|||
|
|
<p>This command runs only the tests in the <em>tests/integration_test.rs</em> file.</p>
|
|||
|
|
<h4><a class="header" href="#submodules-in-integration-tests" id="submodules-in-integration-tests">Submodules in Integration Tests</a></h4>
|
|||
|
|
<p>As you add more integration tests, you might want to make more than one file 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.</p>
|
|||
|
|
<p>Treating each integration test file as its own crate is useful to create
|
|||
|
|
separate scopes that are more like 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 files in the <em>tests</em> directory is most noticeable
|
|||
|
|
when you have a set of helper functions that would be useful in multiple
|
|||
|
|
integration test files and you try to follow the steps in the <a href="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><pre class="playpen"><code class="language-rust">
|
|||
|
|
<span class="boring">#![allow(unused_variables)]
|
|||
|
|
</span><span class="boring">fn main() {
|
|||
|
|
</span>pub fn setup() {
|
|||
|
|
// setup code specific to your library's tests would go here
|
|||
|
|
}
|
|||
|
|
<span class="boring">}
|
|||
|
|
</span></code></pre></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-text">running 1 test
|
|||
|
|
test tests::internal ... ok
|
|||
|
|
|
|||
|
|
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
|
|||
|
|
|
|||
|
|
Running target/debug/deps/common-b8b07b6f1be2db70
|
|||
|
|
|
|||
|
|
running 0 tests
|
|||
|
|
|
|||
|
|
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
|
|||
|
|
|
|||
|
|
Running target/debug/deps/integration_test-d993c68b431d39df
|
|||
|
|
|
|||
|
|
running 1 test
|
|||
|
|
test it_adds_two ... ok
|
|||
|
|
|
|||
|
|
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
|
|||
|
|
|
|||
|
|
Doc-tests adder
|
|||
|
|
|
|||
|
|
running 0 tests
|
|||
|
|
|
|||
|
|
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
|
|||
|
|
</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.</p>
|
|||
|
|
<p>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>. This is an alternate
|
|||
|
|
naming convention that Rust also understands. 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;
|
|||
|
|
|
|||
|
|
mod common;
|
|||
|
|
|
|||
|
|
#[test]
|
|||
|
|
fn it_adds_two() {
|
|||
|
|
common::setup();
|
|||
|
|
assert_eq!(4, adder::add_two(2));
|
|||
|
|
}
|
|||
|
|
</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><a class="header" href="#integration-tests-for-binary-crates" id="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><a class="header" href="#summary" id="summary">Summary</a></h2>
|
|||
|
|
<p>Rust’s testing features provide a way to specify how code should function to
|
|||
|
|
ensure 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>
|
|||
|
|
|
|||
|
|
</main>
|
|||
|
|
|
|||
|
|
<nav class="nav-wrapper" aria-label="Page navigation">
|
|||
|
|
<!-- Mobile navigation buttons -->
|
|||
|
|
|
|||
|
|
<a rel="prev" href="ch11-02-running-tests.html" class="mobile-nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
|
|||
|
|
<i class="fa fa-angle-left"></i>
|
|||
|
|
</a>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
<a rel="next" href="ch12-00-an-io-project.html" class="mobile-nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
|
|||
|
|
<i class="fa fa-angle-right"></i>
|
|||
|
|
</a>
|
|||
|
|
|
|||
|
|
|
|||
|
|
<div style="clear: both"></div>
|
|||
|
|
</nav>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
<nav class="nav-wide-wrapper" aria-label="Page navigation">
|
|||
|
|
|
|||
|
|
<a href="ch11-02-running-tests.html" class="nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
|
|||
|
|
<i class="fa fa-angle-left"></i>
|
|||
|
|
</a>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
<a href="ch12-00-an-io-project.html" class="nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
|
|||
|
|
<i class="fa fa-angle-right"></i>
|
|||
|
|
</a>
|
|||
|
|
|
|||
|
|
</nav>
|
|||
|
|
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
<script type="text/javascript">
|
|||
|
|
window.playpen_copyable = true;
|
|||
|
|
</script>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
<script src="elasticlunr.min.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
|
<script src="mark.min.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
|
<script src="searcher.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
|
|
|||
|
|
|
|||
|
|
<script src="clipboard.min.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
|
<script src="highlight.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
|
<script src="book.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
|
|
|||
|
|
<!-- Custom JS scripts -->
|
|||
|
|
|
|||
|
|
<script type="text/javascript" src="ferris.js"></script>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
</body>
|
|||
|
|
</html>
|