|
|
<!DOCTYPE HTML>
|
|
|
<html lang="en">
|
|
|
<head>
|
|
|
<meta charset="UTF-8">
|
|
|
<title>测试的组织结构 - Rust 程序设计语言 简体中文版</title>
|
|
|
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
|
|
|
<meta name="description" content="Rust 程序设计语言 简体中文版">
|
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
|
|
|
|
<base href="">
|
|
|
|
|
|
<link rel="stylesheet" href="book.css">
|
|
|
<link href='https://fonts.googleapis.com/css?family=Open+Sans:300italic,400italic,600italic,700italic,800italic,400,300,600,700,800' rel='stylesheet' type='text/css'>
|
|
|
|
|
|
<link rel="shortcut icon" href="favicon.png">
|
|
|
|
|
|
<!-- Font Awesome -->
|
|
|
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css">
|
|
|
|
|
|
<link rel="stylesheet" href="highlight.css">
|
|
|
<link rel="stylesheet" href="tomorrow-night.css">
|
|
|
|
|
|
<!-- MathJax -->
|
|
|
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
|
|
|
|
|
<!-- Fetch JQuery from CDN but have a local fallback -->
|
|
|
<script src="https://code.jquery.com/jquery-2.1.4.min.js"></script>
|
|
|
<script>
|
|
|
if (typeof jQuery == 'undefined') {
|
|
|
document.write(unescape("%3Cscript src='jquery.js'%3E%3C/script%3E"));
|
|
|
}
|
|
|
</script>
|
|
|
</head>
|
|
|
<body class="light">
|
|
|
<!-- Set the theme before any content is loaded, prevents flash -->
|
|
|
<script type="text/javascript">
|
|
|
var theme = localStorage.getItem('theme');
|
|
|
if (theme == null) { theme = 'light'; }
|
|
|
$('body').removeClass().addClass(theme);
|
|
|
</script>
|
|
|
|
|
|
<!-- Hide / unhide sidebar before it is displayed -->
|
|
|
<script type="text/javascript">
|
|
|
var sidebar = localStorage.getItem('sidebar');
|
|
|
if (sidebar === "hidden") { $("html").addClass("sidebar-hidden") }
|
|
|
else if (sidebar === "visible") { $("html").addClass("sidebar-visible") }
|
|
|
</script>
|
|
|
|
|
|
<div id="sidebar" class="sidebar">
|
|
|
<ul class="chapter"><li><a href="ch01-00-introduction.html"><strong>1.</strong> 介绍</a></li><li><ul class="section"><li><a href="ch01-01-installation.html"><strong>1.1.</strong> 安装</a></li><li><a href="ch01-02-hello-world.html"><strong>1.2.</strong> Hello, World!</a></li></ul></li><li><a href="ch02-00-guessing-game-tutorial.html"><strong>2.</strong> 猜猜看教程</a></li><li><a href="ch03-00-common-programming-concepts.html"><strong>3.</strong> 通用编程概念</a></li><li><ul class="section"><li><a href="ch03-01-variables-and-mutability.html"><strong>3.1.</strong> 变量和可变性</a></li><li><a href="ch03-02-data-types.html"><strong>3.2.</strong> 数据类型</a></li><li><a href="ch03-03-how-functions-work.html"><strong>3.3.</strong> 函数如何工作</a></li><li><a href="ch03-04-comments.html"><strong>3.4.</strong> 注释</a></li><li><a href="ch03-05-control-flow.html"><strong>3.5.</strong> 控制流</a></li></ul></li><li><a href="ch04-00-understanding-ownership.html"><strong>4.</strong> 认识所有权</a></li><li><ul class="section"><li><a href="ch04-01-what-is-ownership.html"><strong>4.1.</strong> 什么是所有权</a></li><li><a href="ch04-02-references-and-borrowing.html"><strong>4.2.</strong> 引用 & 借用</a></li><li><a href="ch04-03-slices.html"><strong>4.3.</strong> Slices</a></li></ul></li><li><a href="ch05-00-structs.html"><strong>5.</strong> 结构体</a></li><li><ul class="section"><li><a href="ch05-01-method-syntax.html"><strong>5.1.</strong> 方法语法</a></li></ul></li><li><a href="ch06-00-enums.html"><strong>6.</strong> 枚举和模式匹配</a></li><li><ul class="section"><li><a href="ch06-01-defining-an-enum.html"><strong>6.1.</strong> 定义枚举</a></li><li><a href="ch06-02-match.html"><strong>6.2.</strong> <code>match</code>控制流运算符</a></li><li><a href="ch06-03-if-let.html"><strong>6.3.</strong> <code>if let</code>简单控制流</a></li></ul></li><li><a href="ch07-00-modules.html"><strong>7.</strong> 模块</a></li><li><ul class="section"><li><a href="ch07-01-mod-and-the-filesystem.html"><strong>7.1.</strong> <code>mod</code>和文件系统</a></li><li><a href="ch07-02-controlling-visibility-with-pub.html"><strong>7.2.</strong> 使用<code>pub</code>控制可见性</a></li><li><a href="ch07-03-importing-names-with-use.html"><strong>7.3.</strong> 使用<code>use</code>导入命名</a></li></ul></li><li><a href="ch08-00-common-collections.html"><strong>8.</strong> 通用集合类型</a></li><li><ul class="section"><li><a href="ch08-01-vectors.html"><strong>8.1.</strong> vector</a></li><li><a href="ch08-02-strings.html"><strong>8.2.</strong> 字符串</a></li><li><a href="ch08-03-hash-maps.html"><strong>8.3.</strong> 哈希 map</a></li></ul></li><li><a href="ch09-00-error-handling.html"><strong>9.</strong> 错误处理</a></li><li><ul class="section"><li><a href="ch09-01-unrecoverable-errors-with-panic.html"><strong>9.1.</strong> <code>panic!</code>与不可恢复的错误</a></li><li><a href="ch09-02-recoverable-errors-with-result.html"><strong>9.2.</strong> <code>Result</code>与可恢复的错误</a></li><li><a href="ch09-03-to-panic-or-not-to-panic.html"><strong>9.3.</strong> <code>panic!</code>还是不<code>panic!</code></a></li></ul></li><li><a href="ch10-00-generics.html"><strong>10.</strong> 泛型、trait 和生命周期</a></li><li><ul class="section"><li><a href="ch10-01-syntax.html"><strong>10.1.</strong> 泛型数据类型</a></li><li><a href="ch10-02-traits.html"><strong>10.2.</strong> trait：定义共享的行为</a></li><li><a href="ch10-03-lifetime-syntax.html"><strong>10.3.</strong> 生命周期与引用有效性</a></li></ul></li><li><a href="ch11-00-testing.html"><strong>11.</strong> 测试</a></li><li><ul class="section"><li><a href="ch11-01-writing-tests.html"><strong>11.1.</strong> 编写测试</a></li><li><a href="ch11-02-running-tests.html"><strong>11.2.</strong> 运行测试</a></li><li><a href="ch11-03-test-organization.html" class="active"><strong>11.3.</strong> 测试的组织结构</a></li></ul></li><li><a href="ch12-00-an-io-project.html"><strong>12.</strong> 一个 I/O 项目</a></li><li><ul class="section"><li><a href="ch12-01-accepting-command-line-arguments.html"><strong>12.1.</strong> 接受命令行参数</a></li><li><a href="ch12-02-reading-a-file.html"><strong>12.2.</strong> 读取文件</a></li><li><a href="ch12-03-improving-error-handling-and-modularity.html"><strong>12.3.</strong> 增强错误处理和模块化</a></li><li><a href="ch12-04-testing-the-librarys-functionality.html"><strong>12.4.</strong> 测试库的功能</a></li><li><a href="ch12-05-working-with-environment-variables.html"><strong>12.5.</strong> 处理环境变量</a></li><li><a href="ch12-06-writing-to-stderr-instead-of-stdout.html"><strong>12.6.</strong> 输出到<code>stderr</code>而不是<code>stdout</code></a></li></ul></li></ul>
|
|
|
</div>
|
|
|
|
|
|
<div id="page-wrapper" class="page-wrapper">
|
|
|
|
|
|
<div class="page">
|
|
|
<div id="menu-bar" class="menu-bar">
|
|
|
<div class="left-buttons">
|
|
|
<i id="sidebar-toggle" class="fa fa-bars"></i>
|
|
|
<i id="theme-toggle" class="fa fa-paint-brush"></i>
|
|
|
</div>
|
|
|
|
|
|
<h1 class="menu-title">Rust 程序设计语言 简体中文版</h1>
|
|
|
|
|
|
<div class="right-buttons">
|
|
|
<i id="print-button" class="fa fa-print" title="Print this book"></i>
|
|
|
</div>
|
|
|
</div>
|
|
|
|
|
|
<div id="content" class="content">
|
|
|
<a class="header" href="#测试的组织结构" name="测试的组织结构"><h2>测试的组织结构</h2></a>
|
|
|
<blockquote>
|
|
|
<p><a href="https://github.com/rust-lang/book/blob/master/src/ch11-03-test-organization.md">ch11-03-test-organization.md</a>
|
|
|
<br>
|
|
|
commit cf52d81371e24e14ce31a5582bfcb8c5b80d26cc</p>
|
|
|
</blockquote>
|
|
|
<p>正如之前提到的，测试是一个很广泛的学科，而且不同的人有时也采用不同的技术和组织。Rust 社区倾向于根据测试的两个主要分类来考虑问题：<strong>单元测试</strong>（<em>unit tests</em>）与<strong>集成测试</strong>（<em>unit tests</em>）。单元测试倾向于更小而更专注，在隔离的环境中一次测试一个模块。他们也可以测试私有接口。集成测试对于你的库来说则完全是外部的。他们与其他用户使用相同的方式使用你得代码，他们只针对共有接口而且每个测试会测试多个模块。这两类测试对于从独立和整体的角度保证你的库符合期望是非常重要的。</p>
|
|
|
<a class="header" href="#单元测试" name="单元测试"><h3>单元测试</h3></a>
|
|
|
<p>单元测试的目的是在隔离与其他部分的环境中测试每一个单元的代码，以便于快速而准确的定位何处的代码是否符合预期。单元测试位于 <em>src</em> 目录中，与他们要测试的代码存在于相同的文件中。他们被分离进每个文件中他们自有的<code>tests</code>模块中。</p>
|
|
|
<a class="header" href="#测试模块和cfgtest" name="测试模块和cfgtest"><h4>测试模块和<code>cfg(test)</code></h4></a>
|
|
|
<p>通过将测试放进他们自己的模块并对该模块使用<code>cfg</code>注解，我们可以告诉 Rust 只在执行<code>cargo test</code>时才编译和运行测试代码。这在当我们只希望用<code>cargo build</code>编译库代码时可以节省编译时间，并减少编译产物的大小因为并没有包含测试。</p>
|
|
|
<p>还记得上一部分新建的<code>adder</code>项目吗？Cargo 为我们生成了如下代码：</p>
|
|
|
<p><span class="filename">Filename: src/lib.rs</span></p>
|
|
|
<pre><code class="language-rust">#[cfg(test)]
|
|
|
mod tests {
|
|
|
#[test]
|
|
|
fn it_works() {
|
|
|
}
|
|
|
}
|
|
|
</code></pre>
|
|
|
<p>我们忽略了模块相关的信息以便更关注模块中测试代码的机制，不过现在让我们看看测试周围的代码。</p>
|
|
|
<p>首先，这里有一个属性<code>cfg</code>。<code>cfg</code>属性让我们声明一些内容只在给定特定的<strong>配置</strong>（<em>configuration</em>）时才被包含进来。Rust 提供了<code>test</code>配置用来编译和运行测试。通过这个属性，Cargo 只会在尝试运行测试时才编译测试代码。</p>
|
|
|
<p>接下来，<code>tests</code>包含了所有测试函数，而我们的代码则位于<code>tests</code>模块之外。<code>tests</code>模块的名称是一个惯例，除此之外这是一个遵守第七章讲到的常见可见性规则的普通模块。因为这是一个内部模块，我们需要将要测试的代码引入作用域。这对于一个大的模块来说是很烦人的，所以这里经常使用全局导入。</p>
|
|
|
<p>从本章到现在，我们一直在为<code>adder</code>项目编写并没有实际调用任何代码的测试。现在让我们做一些改变！在 <em>src/lib.rs</em> 中，放入<code>add_two</code>函数和带有一个检验代码的测试的<code>tests</code>模块，如列表 11-5 所示：</p>
|
|
|
<figure>
|
|
|
<span class="filename">Filename: src/lib.rs</span>
|
|
|
<pre><code class="language-rust">pub fn add_two(a: i32) -> i32 {
|
|
|
a + 2
|
|
|
}
|
|
|
|
|
|
#[cfg(test)]
|
|
|
mod tests {
|
|
|
use add_two;
|
|
|
|
|
|
#[test]
|
|
|
fn it_works() {
|
|
|
assert_eq!(4, add_two(2));
|
|
|
}
|
|
|
}
|
|
|
</code></pre>
|
|
|
<figcaption>
|
|
|
<p>Listing 11-5: Testing the function <code>add_two</code> in a child <code>tests</code> module</p>
|
|
|
</figcaption>
|
|
|
</figure>
|
|
|
<p>注意除了测试函数之外，我们还在<code>tests</code>模块中添加了<code>use add_two;</code>。这将我们想要测试的代码引入到了内部的<code>tests</code>模块的作用域中，正如任何内部模块需要做的那样。如果现在使用<code>cargo test</code>运行测试，它会通过：</p>
|
|
|
<pre><code>running 1 test
|
|
|
test tests::it_works ... ok
|
|
|
|
|
|
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured
|
|
|
</code></pre>
|
|
|
<p>如果我们忘记将<code>add_two</code>函数引入作用域，将会得到一个 unresolved name 错误，因为<code>tests</code>模块并不知道任何关于<code>add_two</code>函数的信息：</p>
|
|
|
<pre><code>error[E0425]: unresolved name `add_two`
|
|
|
--> src/lib.rs:9:23
|
|
|
|
|
|
|
9 | assert_eq!(4, add_two(2));
|
|
|
| ^^^^^^^ unresolved name
|
|
|
</code></pre>
|
|
|
<p>如果这个模块包含很多希望测试的代码，在测试中列出每一个<code>use</code>语句将是很烦人的。相反在测试子模块中使用<code>use super::*;</code>来一次将所有内容导入作用域中是很常见的。</p>
|
|
|
<a class="header" href="#测试私有函数" name="测试私有函数"><h4>测试私有函数</h4></a>
|
|
|
<p>测试社区中一直存在关于是否应该对私有函数进行单元测试的论战。不过无论你坚持哪种测试意识形态，Rust 确实允许你测试私有函数，由于私有性规则。考虑列表 11-6 中带有私有函数<code>internal_adder</code>的代码：</p>
|
|
|
<figure>
|
|
|
<span class="filename">Filename: src/lib.rs</span>
|
|
|
<pre><code class="language-rust">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 internal_adder;
|
|
|
|
|
|
#[test]
|
|
|
fn internal() {
|
|
|
assert_eq!(4, internal_adder(2, 2));
|
|
|
}
|
|
|
}
|
|
|
</code></pre>
|
|
|
<figcaption>
|
|
|
<p>Listing 11-6: Testing a private function</p>
|
|
|
</figcaption>
|
|
|
</figure>
|
|
|
<p>因为测试也不过是 Rust 代码而<code>tests</code>也只是另一个模块，我们完全可以在一个测试中导入并调用<code>internal_adder</code>。如果你并不认为私有函数应该被测试，Rust 也不会强迫你这么做。</p>
|
|
|
<a class="header" href="#集成测试" name="集成测试"><h3>集成测试</h3></a>
|
|
|
<p>在 Rust 中，集成测试对于需要测试的库来说是完全独立。他们同其他代码一样使用库文件。他们的目的是测试库的个个部分结合起来能否正常工作。每个能正确运行的代码单元集成在一起也可能会出现问题，所以集成测试的覆盖率也是很重要的。</p>
|
|
|
<a class="header" href="#tests-目录" name="tests-目录"><h4><em>tests</em> 目录</h4></a>
|
|
|
<p>Cargo 支持位于 <em>tests</em> 目录中的集成测试。如果创建它并放入 Rust 源文件，Cargo 会将每一个文件当作单独的 crate 来编译。让我们试一试！</p>
|
|
|
<p>首先，在项目根目录创建一个 <em>tests</em> 目录，挨着 <em>src</em> 目录。接着新建一个文件 <em>tests/integration_test.rs</em>，并写入列表 11-7 中的代码：</p>
|
|
|
<figure>
|
|
|
<span class="filename">Filename: tests/integration_test.rs</span>
|
|
|
<pre><code class="language-rust,ignore">extern crate adder;
|
|
|
|
|
|
#[test]
|
|
|
fn it_adds_two() {
|
|
|
assert_eq!(4, adder::add_two(2));
|
|
|
}
|
|
|
</code></pre>
|
|
|
<figcaption>
|
|
|
<p>Listing 11-7: An integration test of a function in the <code>adder</code> crate</p>
|
|
|
</figcaption>
|
|
|
</figure>
|
|
|
<p>在开头使用了<code>extern crate adder</code>，单元测试中并不需要它。<code>tests</code>目录中的每一个测试文件都是完全独立的 crate，所以需要在每个文件中导入我们的库。这也就是为何<code>tests</code>是编写集成测试的绝佳场所：他们像任何其他用户那样，需要将库导入 crate 并只能使用公有 API。</p>
|
|
|
<p>这个文件中也不需要<code>tests</code>模块。除非运行测试否则整个文件夹都不会被编译，所以无需将任何部分标记为<code>#[cfg(test)]</code>。另外每个测试文件都被隔离进其自己的 crate 中，无需进一步隔离测试代码。</p>
|
|
|
<p>让我们运行集成测试，同样使用<code>cargo test</code>来运行：</p>
|
|
|
<pre><code>$ cargo test
|
|
|
Compiling adder v0.1.0 (file:///projects/adder)
|
|
|
Running target/debug/deps/adder-abcabcabc
|
|
|
|
|
|
running 1 test
|
|
|
test tests::it_works ... ok
|
|
|
|
|
|
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured
|
|
|
|
|
|
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
|
|
|
|
|
|
Doc-tests adder
|
|
|
|
|
|
running 0 tests
|
|
|
|
|
|
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured
|
|
|
</code></pre>
|
|
|
<p>现在有了三个部分的输出：单元测试、集成测试和文档测试。注意当在任何 <em>src</em> 目录的文件中增加单元测试时，单元测试部分的对应输出也会增加。增加集成测试文件中的测试函数也会对应增加输出。如果在 <em>tests</em> 目录中增加集成测试<strong>文件</strong>，则会增加更多集成测试部分：一个文件对应一个部分。</p>
|
|
|
<p>为<code>cargo test</code>指定测试函数名称参数也会匹配集成测试文件中的函数。为了只运行某个特定集成测试文件中的所有测试，可以使用<code>cargo test</code>的<code>--test</code>参数：</p>
|
|
|
<pre><code>$ cargo test --test integration_test
|
|
|
Finished debug [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
|
|
|
</code></pre>
|
|
|
<a class="header" href="#集成测试中的子模块" name="集成测试中的子模块"><h4>集成测试中的子模块</h4></a>
|
|
|
<p>随着集成测试的增加，你可能希望在 <code>tests</code> 目录增加更多文件，例如根据测试的功能来将测试分组。正如我们之前提到的，这是可以的，Cargo 会将每一个文件当作一个独立的 crate。</p>
|
|
|
<p>最终，可能会有一系列在所有集成测试中通用的帮助函数，例如建立通用场景的函数。如果你将这些函数提取到 <em>tests</em> 目录的一个文件中，比如说 <em>tests/common.rs</em>，则这个文件将会像这个目录中的其他包含测试的 Rust 文件一样被编译进一个单独的 crate 中。它也会作为一个独立的部分出现在测试输出中。因为这很可能不是你所希望的，所以建议在子目录中使用 <em>mod.rs</em> 文件，比如 <em>tests/common/mod.rs</em>，来放置帮助函数。<em>tests</em> 的子目录不会被作为单独的 crate 编译或者作为单独的部分出现在测试输出中。</p>
|
|
|
<a class="header" href="#二进制-crate-的集成测试" name="二进制-crate-的集成测试"><h4>二进制 crate 的集成测试</h4></a>
|
|
|
<p>如果项目是二进制 crate 并且只包含 <em>src/main.rs</em> 而没有 <em>src/lib.rs</em>，这样就不可能在 <em>tests</em> 创建集成测试并使用 <code>extern crate</code> 导入 <em>src/main.rs</em> 中的函数了。这也是 Rust 二进制项目明确采用 <em>src/main.rs</em> 调用 <em>src/lib.rs</em> 中逻辑的结构的原因之一。通过这种结构，集成测试<strong>就可以</strong>使用<code>extern crate</code>测试库 crate 中的主要功能，而如果这些功能没有问题的话，<em>src/main.rs</em> 中的少量代码也就会正常工作且不需要测试。</p>
|
|
|
<a class="header" href="#总结" name="总结"><h2>总结</h2></a>
|
|
|
<p>Rust 的测试功能提供了一个确保即使改变代码函数也能继续以指定方式运行的途径。单元测试独立的验证库的每一部分并能够测试私有实现细节。集成测试则涉及多个部分结合起来时能否使用，并像其他代码那样测试库的公有 API。Rust 的类型系统和所有权规则可以帮助避免一些 bug，不过测试对于减少代码是否符合期望的逻辑 bug 是很重要的。</p>
|
|
|
<p>接下来让我们结合本章所学和其他之前章节的知识，在下一章一起编写一个项目！</p>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
<!-- Mobile navigation buttons -->
|
|
|
|
|
|
<a href="ch11-02-running-tests.html" class="mobile-nav-chapters previous">
|
|
|
<i class="fa fa-angle-left"></i>
|
|
|
</a>
|
|
|
|
|
|
|
|
|
|
|
|
<a href="ch12-00-an-io-project.html" class="mobile-nav-chapters next">
|
|
|
<i class="fa fa-angle-right"></i>
|
|
|
</a>
|
|
|
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
<a href="ch11-02-running-tests.html" class="nav-chapters previous" title="You can navigate through the chapters using the arrow keys">
|
|
|
<i class="fa fa-angle-left"></i>
|
|
|
</a>
|
|
|
|
|
|
|
|
|
|
|
|
<a href="ch12-00-an-io-project.html" class="nav-chapters next" title="You can navigate through the chapters using the arrow keys">
|
|
|
<i class="fa fa-angle-right"></i>
|
|
|
</a>
|
|
|
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
<!-- Local fallback for Font Awesome -->
|
|
|
<script>
|
|
|
if ($(".fa").css("font-family") !== "FontAwesome") {
|
|
|
$('<link rel="stylesheet" type="text/css" href="_FontAwesome/css/font-awesome.css">').prependTo('head');
|
|
|
}
|
|
|
</script>
|
|
|
|
|
|
<!-- Livereload script (if served using the cli tool) -->
|
|
|
|
|
|
|
|
|
<script src="highlight.js"></script>
|
|
|
<script src="book.js"></script>
|
|
|
</body>
|
|
|
</html>
|
