これは2つの引数の等価性を調べます。"world");}このテストは成功でしょうか、失敗でしょうか。アトリビュートがあるので、これは成功です。使ったテストは脆いテストです。テストが予想外の理由で失敗したのではないということを保証することが難しいからです。パラメータを付けることができます。テストハーネスが、失敗したときのメッセージに与えられたテキストが含まれていることを確かめてくれます。前述の例のもっと安全なバージョンはこうなります。「リアルな」テストを書いてみましょう。いくつかの関数に結果の分かっている引数を渡して呼び出し、期待した結果と比較します。アトリビュートときどき、特定のテストの実行に非常に時間が掛かることがあります。アトリビュートを使ってデフォルトでは無効にすることができます。使って明示的に実行することができます。アトリビュートはテストバイナリの引数であって、Cargoのものではありません。なっているのはそういうことです。モジュール今までの例における手法は、慣用的ではありません。モジュールがないからです。今までの例の慣用的な書き方はこのようになります。}}ここでは、いくつかの変更点があります。このモジュールを使うと、全てのテストをグループ化することができます。必要であれば、ヘルパ関数を定義し、それをクレートの一部に含まれないようにすることもできます。アトリビュートによって、テストを実行しようとしているときにだけテストコードがコンパイルされるようになります。これは、コンパイル時間を節約し、テストが通常のビルドに全く影響しないことを保証してくれます。ここは内部モジュールの中なので、テスト関数をスコープの中に持ち込む必要があります。モジュールが大きい場合、これは面倒かもしれないので、ここがグロブの一般的な使い所です。グロブを使うように変更しましょう。行が変わったことに注意しましょう。モジュールは「ユニット」テストを入れるために使うことになっています。単一の小さな機能の単位をテストするものは全て、ここに入れる意味があります。「結合」テストはどうでしょうか。ディレクトリがあります。ディレクトリを作りましょう。adder::add_two(2));}これは前のテストと似ていますが、少し違います。ディレクトリの中のテストが全く別のクレートであるため、ライブラリをインポートしなければならないからです。結合テストを書くのに適切な場所なのかという理由でもあります。そこにあるテストは、そのライブラリを他のプログラムと同じようなやり方で使うからです。テストを実行しましょう。measured今度は3つのセクションが出力されました。新しいテストが実行され、前に書いたテストも同様に実行されます。ディレクトリについてはそれだけです。モジュールはここでは必要ありません。全てのものがテストのためのものだからです。最後に、3つ目のセクションを確認しましょう。ドキュメンテーションテストです。ドキュメンテーションテスト例の付いたドキュメントほどよいものはありません。ドキュメントを書いた後にコードが変更された結果、実際に動かなくなった例ほど悪いものはありません。これはライブラリクレートの中でのみ動作し、バイナリクレートの中では動作しません)。付けていることに注意しましょう。RustのドキュメントはMarkdown形式のコメントをサポートしていて、3連バッククオートはコードブロックを表します。セクションを含めるのが慣習で、そのとおり、例が後に続きます。テストをもう一度実行しましょう。ドキュメンテーションテストの名前に注意しましょう。関数テストのために生成された名前です。いうような形で数値が増えていきます。ドキュメンテーションテストの書き方の詳細について、全てをカバーしてはいません。