第3回　結合テストをする理由 - テスト講座

チームで開発する難しさ

単純で小規模なWebアプリケーションであれば一人で開発することがあるかもしれませんが、規模が少し大きくなったり、納期が短い等の理由で複数人で開発することも少なくないはずです。

複数人で開発する場合、それぞれの開発者が並行で作ったものを組み合わせてきちんと動作するかということが問題になってきます。この段階で問題になるのは次のようなパターンです。

• そもそも単体で動いていない

  この段階で単体で動いていないのはその部分を担当した開発者がきちんとテストをしていないことが問題ですね。チームで開発している場合、組み合わせる前に単体で仕様通りに動いているかのテストは最低限しておくべきです。
  この部分は単体テスト(UnitTest)の領域ですので、詳しい説明は次回以降に譲りますが、この状態であるということはチームに多大な迷惑をかけているということを認識する必要があります。

• 単体では動いているが組み合わせると動かない

  この状態になるのはいろいろなパターンがあると思いますが、次のような状態になっていることが多いのではないでしょうか?

  • AからBを呼び出しているとして、Bが想定していない呼び方をAがしてしまっている

  単純にAの動作が設計外であることが悪い場合もありますし、Bの設計の理解が足らなくて作り込みが不完全ということもあるでしょう。どちらにしてもやはり正しく動作しません。

ここまでで説明したとおり、複数人で開発したものを組み合わせたものが仕様通りに動作するかのテストを"結合テスト"といいます。結合テストを行うことにより、上記のような認識の違いや、仕様の理解不足を発見することができます。そして、結合テストがきちんと通れば、それぞれの開発で事前に認識あわせした通りに動いたと言えるでしょう。

Webアプリの結合テストって面倒臭い

Webアプリケーションの結合テストというのは通常Webブラウザからアクセスして正しく動作すること(または、正しくエラーがでること)をチェックするということが多いのではないでしょうか。

Webブラウザからのテストというのは次のようなことを行います。

• 画面上のリンクやボタンをクリックして仕様通りの画面に遷移すること
• 入力フォームがある場合、仕様通りの入力を行った場合はエラーにならずに仕様通りの画面に遷移すること
• 入力フォームがある場合、仕様外の入力を行った場合はエラーであることを画面に表示すること
• システムで問題が発生した場合にエラーが表示されること ... etc.

少ない画面数であれば、テスト担当者が1つ1つ画面を見ながら行うこともそれほど大変でありませんが、画面数が多い場合、全画面全パターンのチェックを手動で行っていくということは大変手間がかかります。

その手間を惜しんでテストがおろそかになり、テストをしていなかった画面でエラーが報告されるということを経験された方も多いのではないでしょうか?

回帰テスト

結合テストをした結果、全く問題点(バグ)が見つからないということはあまりないと思います。たいていの場合、結合テストで何らかの問題点が発見されて、その問題の箇所を修正することになると思います。

さて、修正作業をした場合、その後テストはどのようにすればよいでしょうか？

関係している(もしくは関係すると予想される)場所のみをテストする場合が多いと思いますが、この段階でどこが関係しているかということを正確に把握できているでしょうか?

バグを修正したら全く予想外のところに影響が出て、また違ったところで不具合が起きるということを延々と繰り返した経験はありませんか?

本来ならば全ての結合テストをやり直すことができればよいのですが、修正するたびに全てのテストを手動でやり直すというのは現実的ではない場合があります。

この"手動でやり直す"というのがもし"自動でやり直す"ことができればどうでしょうか? さらにそれが短い時間で完了すればどのようなことになるでしょうか?

まずは、最初の結合テストの手順を見てみましょう。今回は何らかの方法で結合テストが自動化できているという前提になっています。

• (1) 結合テストを自動で行う準備を行う
• (2) 結合テストを自動で実行する
• (3) バグがあれば(4)へ、バグがなければ終了
• (4) バグを修正する
• (5) (2)に戻る

上記の手順で結合テストを完了して、無事リリースが完了したとしましょう。そして3ヶ月後仕様変更がかかったとします。そこでの作業は次のようなものになると思います。

• (a) 仕様変更部分を開発する(もしくは修正する)
• (b) 結合テストに仕様変更部分を追加する
• (c) 結合テスト(初期開発分+仕様変更分)を自動で実行する
• (d) バグがあれば(e)へ、バグがなければ終了
• (e) バグを修正する
• (f) (c)に戻る

上記の(c)の手順では単純に仕様変更部分だけがテストされるのではなく、初期開発時に実行した部分のテストも併せて行われます。これにより仕様変更部分だけでなく、本来仕様変更とは関係ないと思っていた部分もテストすることができます。

このように蓄積したテストを使って修正していない部分に関してもテストをしていくテストを"回帰テスト"といいます。

"回帰テスト"として実行させるものの蓄積が増えれば増えるほど、未然に問題を発見することができ、安心して修正することができます。

この回帰テストを何度も繰り返し行うためにはそれが自動化されていることが重要です。そのためのツールとして使用されているものの代表例として、"Selenium"があります。