"設計に対する信頼は、コードが動くことではなく、構文として明文化されるべきだ。"
ソフトウェア開発における“テスト”とは、結果としての成功/失敗ではなく、設計そのものの信頼性に対する構造的証明行為である。
Rustにおける #[test] 属性は、その構造をもっとも直接的に明示する装置だ。
この章では、#[test] が単なる注釈にとどまらず、**「この関数はテストであり、信頼の根拠としてコンパイル時に保証されるべきものである」**という設計的表明であることを掘り下げる。
#[test]：属性としての“設計契約”
#[test]
fn should_add_correctly() {
assert_eq!(sum(1, 2), 3);
}
この #[test] は、関数の振る舞いを変えるものではない。
それは、この関数が「検証のために存在している」という意図をコンパイラに伝える構文上の契約である。
つまり #[test] は、「この関数は本番用途ではなく、設計の正しさを示すものである」という語りの形式なのだ。
テストコードは設計者による「実行されるドキュメント」
ドキュメントは書かれても読まれない。
だが #[test] によって書かれたコードは、機械によって定期的に評価され、失敗すれば即座に通知される。
これは、次のような構造をもつ：
- ドキュメントよりも正確
- 実装よりも抽象的
- 使用よりも未来志向
Rustのテストは、**“設計者の設計意思がコンパイル時から実行時まで一貫して保証される構文的意思表明”**である。
cargo test の実行は「構造の検証」である
cargo test を走らせるという行為は、次のことを意味している：
- コンパイラが
[cfg(test)]を含む構文をビルドし -
#[test]の付いた関数を自動で収集し - それぞれを独立した検証単位として実行する
この自動化こそが、**「設計者の意思を形式化して反復可能にする」**というRust流の品質保証哲学である。
Rustは、テスト実行すら設計に組み込むことを言語の構文設計の一部にしている。
テストとは、「壊れない」のではなく、「壊れたら分かる」構造である
Rustの #[test] は、完全性ではなく、明示的失敗の設計を支援する。
#[test]
fn fails_when_negative() {
let result = parse_positive("−42");
assert!(result.is_err());
}
このようなテストは、「この入力には失敗するのが正しい」という構文的保証を意味している。
つまり #[test] は、「正しい失敗すらも、構文の中で意味づけることができる」保証の枠組みでもある。
テストの粒度は“設計の語彙力”に比例する
良いテストとは、以下のような性質を持つ：
- テスト名が「何を検証しているか」を説明できる
-
assert文が仕様の一部を映している - テスト群として「設計の輪郭」を再構成できる
Rustでは、#[test] 関数はひとつの命題であり、その命題の集合が設計全体の意味構造を裏打ちする。
#[test]は“構文的構成主義”の核である
Rustは、設計を構文で語る言語である。
#[test] はその最前線にあり、以下の機能を担う：
- 開発者に検証の責任を要求する
- 設計者に仕様の定義を強制する
- コンパイラにその保証を負わせる
Rustの哲学は、「動くコードより、壊れたときに意味がある構造」を重視する。
そして #[test] は、その構造が本当に意味を持つかを照らす反射光である。
結語：#[test]は構文の中の倫理である
Rustにおける #[test] は、単なるテスト関数の指定ではない。
それは、「この設計には、検証可能な正しさがあるべきだ」という構造的倫理の宣言である。
テストコードは設計の語りであり、#[test] はそれを構文として形式化する構造的信頼の道具である。
だからこそRustは、あらゆる関数にこの属性を与える自由を許しつつ、
その使用を設計的義務として、開発者に課している。
"信頼される設計とは、テストによって検証された設計ではない。検証されるべき設計を構文として書けることである。"