タイトルに反して、どうやらWikipediaによると型チェックはソフトウェアテストではないらしい。
プログラムを実行し、正しく動作するかどうか確認する作業
（略）
欠陥が存在することを示すことはできるが、欠陥が存在しないことは証明できない。
型チェックは一部ではあるものの、プログラムを実行するまでもなく正しく動くことを確認でき、欠陥が存在しないことの証明ができてしまうからだ。
しかし型チェックはテストコード同様、「プログラムの動作部分ではないが、プログラマのミスを避けるために追加で書かれるコード。本質的には無くてよい」ものであることに違いはない。
型チェックもソフトウェアテストってことにしておこうよ
従来のソフトウェアテストを「帰納的テスト」、型チェックのようなものを「演繹的テスト」と呼びたい。
型チェック自体をテストとすれば多くのソフトウェア開発でTDDを行っていることになる。これは単なる言葉遊びではない。
- 型を先に書くことで実装コードの見通しを立てやすくする
- 型チェックを用いて安心してリファクタリングを行える
- 高速に動作するため、頻繁にテストを行える
- 型を書かないと実行すらできないのでテストの記述を強制できる
- コードカバレッジは常に100%
- テストを書くべき部分と書かなくてよい部分の境界が曖昧にならない
素晴らしい。テスト駆動開発のメリットのほとんどを享受できるではないか。
必要であれば演繹的テストに加えて帰納的テストを加えればよい。
従来のテスト設計と同様に型の設計はソフトウェアの品質において大いに貢献する。Javaのような言語ですらint型の代わりにUserId型を使うだけでもかなりのミスが防げる。まして型システムが強力な言語においては言うまでもない。
終わりに
半分ジョークではあるが、「ソフトウェアテスト！自動化！テスト駆動開発！」と叫ぶ人たちがあまり型の話をしないので、書いてみた。
より多くの人に「型チェックすげー」と言ってもらいたい