"テストはコードを検査する行為ではない。それは、設計が信頼に足るかどうかを問う対話である。"
ソフトウェアの品質は、テストによって保証される。
それは誰もが知る常識でありながら、そのテストが設計にどれだけ踏み込めているかを問い直す場面は少ない。
Rustは、テストにすら言語的構文による設計思想の適用を求める。
この章では、Rustにおける単体テストがなぜ特別なのか、
それが**「コードの正しさ」ではなく「構造の信頼性」**を保証するための倫理装置として機能する理由を解き明かしていく。
テストは「コードの外部にある構文」である
Rustのテストは、関数の前に #[test]
属性をつけるだけで始まる。
#[test]
fn it_adds_two() {
assert_eq!(2 + 2, 4);
}
この構文は、テストを「特別な責務を持つ関数」として明確に切り出している。
そしてこの関数は、プロダクションコードとは分離された宇宙に存在する。
つまりRustは、「テストはコードの一部ではなく、構造への外的評価である」という立場をとっている。
cargo test
:コンパイルされた信頼の実行
テスト関数は通常の main()
とは異なるバイナリにリンクされ、cargo test
によって実行される。
ここでRustがしているのは、**「テスト対象そのものとは別の文脈でコードを評価する構造」**の生成である。
このアプローチは以下を可能にする:
- 本番ロジックとテストを明確に分離
- テスト用の依存関係(
dev-dependencies
)の切り出し - テストの存在そのものがコードベースに組み込まれている状態を防ぐ
Rustは、テストを“実行ではなく設計の検証”として再定義している。
assert_eq!
, should_panic
, #[ignore]
:構文で設計意図を語る
Rustのテストでは、ただの真偽判定ではなく、構文で意図を語る。
#[test]
#[should_panic(expected = "division by zero")]
fn it_panics() {
let _ = 1 / 0;
}
これは単なる「クラッシュの確認」ではなく、**「この構造はこの条件で壊れてよい」という明示的な設計」**である。
設計者が「壊れてよいポイント」を構文で語れる、数少ない言語的機構だ。
また #[ignore]
は、**「このテストは一時的に除外すべき理由がある」**ことを、明示的に設計に残す。
テストモジュールは“設計の内部可視化領域”
Rustでは、テストは #[cfg(test)]
を使ってモジュール内に埋め込むことができる。
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn it_works() {
assert_eq!(sum(2, 3), 5);
}
}
これは「内部構造へのアクセスを許された、設計者の試験場」という位置づけである。
- 内部関数やモジュールの直接テストが可能
-
use super::*
により、そのモジュールを直視できる - 本番環境には影響を与えない(cfg属性による分離)
この構文分離が、「本質を壊さずに内部を問い直す構造的試験」を可能にする。
テスト関数は関数ではなく、“証明”である
Rustの #[test]
関数は、返り値を持たない(fn foo() {}
)にもかかわらず、
失敗すればそれが Err
のように扱われ、テスト全体を落とす。
この構造は、テスト関数=命題の証明という意味を持つ。
-
assert!
は仮定の論理式 -
panic!
は否定の証明 -
#[should_panic]
は逆説の受容
Rustでは、「テストを書く」とは「この構造がこの条件で保証されるべきであるという倫理宣言」なのだ。
Rustのテストは「未来のコードの保護装置」である
単体テストは、今のコードに対する検査ではない。
それは未来の自分、未来の設計者に対して:
- 「ここに意図がある」
- 「この振る舞いが仕様である」
- 「この制約を壊すなら意図が必要だ」
という設計的境界線を構文で残すための装置である。
テストとは信頼の記録であり、変更に対する防波堤だ。
結語:テストは責任を残す構文である
Rustにおける単体テストは、構文が持つ意味を最大限に活かして、
**「設計は検証されるべきである」「検証は構文で透明化されるべきである」**という態度を明確に示している。
-
#[test]
は検査の開始点 -
assert!
は信頼の定式化 -
#[should_panic]
は例外を含めた仕様の言語化 -
#[cfg(test)]
は構造的可視性の範囲指定
Rustは、テストさえも“構文で構造を語る場”として扱う数少ない言語である。
"設計とは信頼の記録であり、テストとはその記録を構文で遺す倫理的形式である。"