修正格式错误ch11-01

src/ch11-01-writing-tests.md

@@ -40,7 +40,7 @@ adder 库中 _src/lib.rs_ 的内容应该看起来如示例 11-1 所示：
 
 现在让我们只关注 `it_works` 函数本身。注意 `fn` 行之前的 `#[test]`：这个属性表明这是一个测试函数，这样测试执行者就知道将其作为测试处理。`tests` 模块中也可以有非测试的函数来帮助我们建立通用场景或进行常见操作，必须每次都标明哪些函数是测试。
 
-示例函数体通过使用 `assert_eq!` 宏来断言 `result` （其中包含 2 加 2 的结果） 等于 4。一个典型的测试的格式，就是像这个例子中的断言一样。接下来运行就可以看到测试通过。
+示例函数体通过使用 `assert_eq!` 宏来断言 `result` （其中包含 2 加 2 的结果）等于 4。一个典型的测试的格式，就是像这个例子中的断言一样。接下来运行就可以看到测试通过。
 
 `cargo test` 命令会运行项目中所有的测试，如示例 11-2 所示：
 
@@ -74,7 +74,7 @@ Cargo 编译并运行了测试。可以看到 `running 1 test` 这一行。下
 {{#include ../listings/ch11-writing-automated-tests/no-listing-01-changing-test-name/output.txt}}
 ```
 
-现在让我们增加另一个测试，不过这一次是一个会失败的测试！当测试函数中出现 panic 时测试就失败了。每一个测试都在一个新线程中运行，当主线程发现测试线程异常了，就将对应测试标记为失败。第九章讲到了最简单的造成 panic 的方法：调用 `panic!` 宏。写入新测试 `another` 后， _src/lib.rs_ 现在看起来如示例 11-3 所示：
+现在让我们增加另一个测试，不过这一次是一个会失败的测试！当测试函数中出现 panic 时测试就失败了。每一个测试都在一个新线程中运行，当主线程发现测试线程异常了，就将对应测试标记为失败。第九章讲到了最简单的造成 panic 的方法：调用 `panic!` 宏。写入新测试 `another` 后，_src/lib.rs_ 现在看起来如示例 11-3 所示：
 
 <span class="filename">文件名：src/lib.rs</span>