前回は3日目に3つ学んだことの中の2つめ「テストを整理する方法」についてまとめました。今回は3日目に学んだことの最後、3つめである「何をテストするか」についてまとめます。

このまとめはインターンシップ時に書いたメモを読み返しながら書いています。数日前にこのURLのパスを変えました。当初は「/2013/...」と開催年を使っていたのですが、「/2/...」と通算何回目のインターンシップかを使うことにしました。理由は2013年に2回インターンシップを実施することになったため、開催年がインターンシップを識別するユニークな情報ではなくなったからです。

どこまでテストするか

テストを書いた方がよいことはわかった、テストを整理する方法もわかった、どんどんテストを書いていける。そんな状態でテストを書き始めると、たくさんテストを書いてしまいます。テストがたくさんあることはよいことのように聞こえますが、必ずしもよいこととは限りません。テストがたくさんあると以下のようなことが起きます。

• テストが遅くなる。
• テストのメンテナンスが大変になる。

どちらも「テストはいらない」と感じる原因になります。

テストが遅くなるとテストを実行することが面倒になります。面倒になるとテストを実行しなくなります。テストを実行しないと「テストがあっても意味ないね」と思うようになり、「テストはいらない」と感じるようになります。

APIの変更などでテストを変更する必要があったとき、テストが多いとテストの修正が大変になります。テストのメンテナンスが大変になるということです。テストのメンテナンスが大変になるとテストの作成・変更が開発の足をひっぱるようになり、機能の追加や修正作業に影響がでます。そうすると、自分達は「機能の追加や修正をしたいはずなのにテストばかりに時間を使っている、これでは本末転倒じゃないか」と思うようになり、「テストはいらない」と感じるようになります。

補足しておくと、どちらもテストがたくさんあることだけが原因ではありません。原因の1つというだけです。例えば、データベースに接続しているために遅くなる場合もありますし、テストが整理されていないためにメンテナンスが大変になる場合もあります。データベースに接続して遅くなっているなら、スタブを使って速くすることができますし、テストを整理することでメンテナンスを簡単にすることもできます。ここでは、テストの多さに注目するというだけです。

せっかくテストの恩恵を得るためにたくさんテストを書いたのに、「テストいらないかも…」と感じるようになってはもったいありません。そうならないために、適切な量のテストだけ書きましょう。

適切な量のテスト

適切な量のテストとは「実質的に同じこと」を含まないテストです。「同じこと」ではなく「実質的に同じこと」です。

例えば、以下の2つのアサーションは「同じこと」を確認しています。

assert_equal(11, 2 + 9)
assert_equal(11, 2 + 9)

以下の2つのアサーションは「実質的に同じこと」を確認しています。

assert_equal(11, 2 + 9)
assert_equal(12, 3 + 9)

以下ようにすると「実質的に違うこと」を確認しています。

assert_equal(11, 2 + 9)
assert_equal(-7, 2 + -9)

実質的に同じかどうかを判断するポイントは、入力値がどの分類に属しているかです。入力値が同じ分類なら「実質的に同じ」です。

「2 + 9」を「正の整数 + 正の整数」と考えると、「2」も「3」もどちらも同じ「正の整数」という分類に入るので、「2 + 9」も「3 + 9」も実質的に同じです。

一方、「-9」は「負の整数」という分類になるので、「2 + 9」と「2 + -9」は実質的に違います。

分類をどう考えるかは「何を基準にするか」で変わってきます。たとえば、偶数か奇数かという基準にすれば「2」と「3」は実質的に違います。

どうやって基準を見つけるか

どうやって適切な基準を見つければよいか、そのやり方はまだうまくまとめられていません。テストを書いているときは、基準を考えて、分類し、実質的に違うことだけ確認しようとしているので、何かしらやり方をもっているような気がしますが、それを他の人に説明するところまではいっていません。「境界値を見つける」など説明できることはありますが、それだけではない気がしています。もっと何か別のやり方を持っている気がします。それらについてもうまく説明できるようになることは今後の課題です。

ただ、具体的にこの場合はどうするか？ということには答えることができます。1つ紹介します。

以下のようなテストがありました。

def test_title
  epub_book_doc_all = EPUB::Parser.parse(fixture_path('empty_contributors_single_spine.epub'))
  @document_all = EPUBSearcher::EPUBDocument.new(epub_book_doc_all)

  epub_book_doc_11_12 = EPUB::Parser.parse(fixture_path('single_contributors_multi_spine.epub'))
  @document_11_12 = EPUBSearcher::EPUBDocument.new(epub_book_doc_11_12)

  assert_equal("groongaについて", @document_all.title)
  assert_equal("groongaについて", @document_11_12.title)
end

@document_allと@document_11_12の違いはコントリビューターの数とspineの数です。タイトルは同じです。

このときは、テスト対象の「タイトル」を基準に分類します。タイトルに違いがないなら、コントリビューターの数が違ってもspineの数が違っても同じ分類と考えます。同じ分類なら実質的に同じです。

書いてみて気づきましたが、テストで何に注目しているかを考えることが基準を見つけるやり方のひとつのような気がしますね。まとめてよかったです。

まとめ

インターンシップで説明した何をテストするかについてまとめました。インターンシップのときはうまく説明できなかったのですが、こうしてまとめてみたら整理された気がします。よかったです。

ツイートする

フォローする