こんにちは！最近転職して新宿までロマンスカーにお世話になりっぱなしの ikasam_a です。
Test Track 3日目です！初日に xaicron さんから「テストの細かい話を書いて！」と言われたので、今日はちょっと趣向を変えて、テストの分類についてつらつらと書いてみたいと思います。
あまり、というかまったく Perl の話は出てこないです！さーせん！
例えばチームでテストの話をするような時に、それぞれが考える「テスト」のイメージが違って、話が噛み合わないことがあったりしますよね。僕はよくありました。
僕は「テスト＝単体テスト」の話をしているつもりが、相手は「テスト＝機能テスト」だと思って話を進めていると、あれ？という場面があったりします。こういうときは、例えば設計におけるデザインパターンのように、テストをより具体的にした共通認識があると話が捗ります。
そんなわけで、僕の主観でテストを分類したところ紆余曲折ありましたがそれは省略して、この4つの軸に落ち着きました！
これらの軸でテストを分類するとどうなるか、もう少し細かく見ていきます。
テスト視点の分類には、以下の3つのテストがあります。
開発者テストは、開発者自身が開発中に行うテストです。コードを書いたら prove する、というのがまさしくこれですね。モジュール書いたら開発者テストをしてくださいね！
リリーステストは、読んで字のごとく「リリースするよ！」の時に行うテストです。QAとして開発者以外の第3者が行うことが多いかと思います。
受け入れテストも名前はよく聞きますよね。これはソフトウェアの受け渡し先で実施するテストで、大体は「納品先のお客様」が行う前提で話されることが多いですね。
テスト視点の分類は、誰がテストするかによる違いもそうですが、言い換えれば開発プロセスのどのタイミングで行うかの違いも同時に表しているのが特徴です。
次はテスト対象での分類です。テストの対象物がどの大きさなのかで分かれています。
単体テストや結合テストという表現はよく目にしますが、他にも統合テストとか総合テストといった表現が出てくる場合もあると思います。単体テストは対象が1つなのだとわかりますが、結合・統合・総合は何が違うのかわかりにくいと思います。というか僕はよくわからなかったので、あえて単体テストと結合テストの2つだけで区別しています！
ただ単体テストや結合テストと言うだけではイマイチわかりにくいので、モジュール単体テスト/モジュール結合テスト、アプリケーション単体テスト/アプリケーション結合テスト、というように規模感を表す接頭語をつけるとよりわかりやすくなっていいですね！
これはいわゆるテストの書き方です。
内部構造を知った上でそれを利用してテストを書くのがホワイトボックスで、逆に内部にはまったく関知せず、入力と出力に特化してテストを書くのがブラックボックスですね。
いわゆる「モックを当てる」みたいなテストはホワイトボックスの代表例ですね。今やこういう書き方も当たり前になりましたね！
なお、両方の特性を持ったグレーボックスというのもあるみたいなんですが、意味が曖昧になるので入れませんでした。
最後はテスト目的です。言うなれば何を知りたくてテストするのか、という感じですね。
大きく分けると、ソフトウェアの機能（〜〜できるっていうアレ）をテストする機能テストと、性能面などの非機能と言われる部分をテストする非機能テストの2つですね。
非機能テストは更にパフォーマンステスト/負荷テストなどに細分類できますが、ここではその詳細は省略します。
4つの異なる分類軸があるということは、
ということが言えると思います。
しばしば「単体テストをやって次に機能テストをやろう」みたいな表現を聞きますが、これは上の定義からするとおかしいことになりますね。単体テストと結合テストを比較するならすっきりしますし、あるいは単体テストとして機能テストを行う、即ち同時に行うことも可能です。
分類軸を用意すると、明確な基準がある状態でテストの比較ができますし、分類軸が違うテストを曖昧に比較してしまうことも無くなると思います。
なんだか書いていて自分でも難しくなって来ました！
強引にまとめると「開発者テストとしてモジュール単体の機能を確認するブラックボックステストを書く」と言えると、今やろうとしているテストが明確になって、変な誤解なしに議論ができると思います！
というわけで長くなりましたが、今日は、僕がテストの話をするときにいつも考えている分類について書きました。
みなさんもテストの話をする時は、どこに着目しているかをはっきりさせると、互いの理解が早まって良いと思います！その時に今日のテスト分類がお役に立てばと思います！
さて明日は（本当は怖くないって噂の） tokuhirom さんです！ｄｋｄｋ！お楽しみに！