はじめに
#NO IMAGEThe Rust Programming Language 日本語版 - The Rust Programming Language 日本語版
を読んでいる
今日読む場所
#NO IMAGEテストの実行のされ方を制御する - The Rust Programming Language 日本語版
お勉強
#cargo test -- --nocapture
- こういう引数にすれば標準出力のテストが成功しても出力されるようになる
- フーン
pub fn add_two(a: i32) -> i32 {
a + 2
}
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn add_two_and_two() {
assert_eq!(4, add_two(2));
}
#[test]
fn add_three_and_two() {
assert_eq!(5, add_two(3));
}
#[test]
fn one_hundred() {
assert_eq!(102, add_two(100));
}
}
- これがあって
$ cargo test one_hundred
Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
Running target/debug/deps/adder-06a75b4a1f2515e9
running 1 test
test tests::one_hundred ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 2 filtered out
- こうやると1つしか実行されない
- これはデバッグで使えそう
テスト名の一部を指定でき、その値に合致するあらゆるテストが走ります。例えば、 我々のテストの2つがaddという名前を含むので、cargo test addを実行することで、その二つを走らせることができます:
- integrationとかunitとかの名前に含めておくのかしら
#[test]
fn it_works() {
assert_eq!(2 + 2, 4);
}
#[test]
#[ignore]
fn expensive_test() {
// 実行に1時間かかるコード
// code that takes an hour to run
}
- こうやると、普段は無視されるけど
cargo test -- --ignored
Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
Running target/debug/deps/adder-ce99bcc2479f4607
running 1 test
test expensive_test ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 1 filtered out
- こうやると含んでtestができる
章の初めで触れたように、テストは複雑な鍛錬であり、人によって専門用語や体系化が異なります。 Rustのコミュニティでは、テストを2つの大きなカテゴリで捉えています: 単体テストと結合テストです。
- お
testsモジュールの#[cfg(test)]という注釈は、コンパイラにcargo buildを走らせた時ではなく、cargo testを走らせた時にだけ、 テストコードをコンパイルし走らせるよう指示します。
- fmfm
このコードが自動生成されたテストモジュールです。cfgという属性は、configurationを表していて、 コンパイラに続く要素が、ある特定の設定オプションを与えられたら、含まれるように指示します。
- こういうのを知りたい
テストコミュニティ内で非公開関数を直接テストするべきかについては議論があり、 他の言語では非公開関数をテストするのは困難だったり、不可能だったりします。
- 非同期じゃなかった、privateってことか
結合テストを作成するには、 まずtestsディレクトリが必要になります。
- ほーこっちが結合って文化なんだね
extern crate adder;
#[test]
fn it_adds_two() {
assert_eq!(4, adder::add_two(2));
}
tests/integration_test.rsのどんなコードも#[cfg(test)]で注釈する必要はありません。 Cargoはtestsディレクトリを特別に扱い、cargo testを走らせた時にのみこのディレクトリのファイルをコンパイルするのです。 さあ、cargo testを実行してください:
- あーcargoの仕様なんだ
$ 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
- いいじゃーん、ciで便利そう
pub fn setup() {
// ここにライブラリテスト固有のコードが来る
// setup code specific to your library's tests would go here
}
メモ
#まとめ
#- 思ったより量が多くてサクっと読めなかった
- 基本的には知っていることしかなくて、実装時にこんな実装できたはずって思いだす作業な気がする
- 次はこれ