お世話になっております。

PHP をメインにして Web アプリを制作している者です。今回は Web アプリで効率よく単体テストを実装するための手法についての質問です。

現在、前任者から引き継いだ案件をひとりでやっているのですが、単体テストがろくに実装できていないため、回帰テストが綿密に実施できず、品質がなかなか保証できません。

以前の質問で、
http://q.hatena.ne.jp/1172210806
ということで SeleniumIDE を教えていただき、さっそく活用しているのですが、これだとどちらかというと統合テスト寄りのテストになってしまいます。

そこでテスト・ツールとしては PHPUnit(現状では PHP4 を使っているので) を導入し、単体テストを組み込もうとしていますが、テスト対象の関数の粒度や Web 帳票の出力ということから、テストの実装に躓いています。

そこで質問です。
Web アプリに対する単体テストの実装で参考になる資料を御存知ないでしょうか?

以上、宜しくお願いします。

回答の条件
  • 1人2回まで
  • 登録:2007/08/24 13:29:27
  • 終了:2007/08/29 13:56:17

回答(2件)

id:sukiyaki22 No.1

sukiyaki22回答回数299ベストアンサー獲得回数22007/08/25 00:47:56

phpをインストールすればいいんじゃないですか?むつかしいですか?

id:renpoo

質問の趣旨をまったく理解されていないので最低ポイントにさせていただきます。

2007/08/25 00:52:02
id:KUROX No.2

KUROX回答回数3542ベストアンサー獲得回数1402007/08/25 04:25:56

ポイント70pt

単体テストがしやすい構造に設定してくださいというのが

わたしの考えです。だから今回はそうなってないので

つらいんじゃないかなとも思います。

------------------------------------------------

単体のUnitテストがしやすいような、設計になってないと

うまくいかない場合が多いです。

関数の粒度をきめれないのもそのためだと思います。

Web 帳票の出力もどっちかというと結合テストよりだと思います。

単体のUnitで異常を検地した場合は、ソース変更がまずいと

言うことが分かりますが、検地しなかった場合は、大丈夫か

そうでないかは本当は分からないと思います。

--------------------------------------------------

コメントに書いていらっしゃることは、すでに単体テストを

超えていると思います。モジュール(クラス)がある一定上に

相互関係でないと動かない場合は、単体テストでは思えません。

id:renpoo

回答ありがとうございます。

やはり、おっしゃる通りのようですね。

コメントにあるような画面要素は、単なる代入か、あるいはライブラリ関数でプルダウン・リストなどに展開されています。もちろん、これらライブラリ関数の粒度はそれなりに小さく、単体テストも実装しやすいです。

ですが、おっしゃる通り、若干の連動項目(プルダウン A の選択によってプルダウン B が変化する)があるくらいですし、画面によっては入力項目数が多いので、統合テストとして認識するしかないのでしょう。


もしかすると、現段階では無理に単体テストを実装しようと四苦八苦するより、テスト・ケースを整備して(画面の)統合テストのケースを増やすほうが、賢い選択かもしれません。

テスト・ケースの生成には「HAYST 法」というものを勉強しています。実験計画法の直交表の応用です。

もし、機能組み合わせ的に網羅的なケース群を Excel かなにかの補助で生成することができれば、ケースへのバグ混入率も下げることができ、再現性もあり、なおかつ SeleniumIDE 用のテスト・ケースへのコンヴァートも視野に入ってくるでしょう。

御意見をいただけたおかげで発想の方向が変わってきました。よい検討材料ができたということで感謝します。m(_ _)m

2007/08/25 05:00:50
  • id:renpoo
    勘違いをなさって回答する方もいらっしゃるので、若干、補足説明を。

    ユーザーによる帳票入力をデータベースに記録して、のちのち統計分析するシステムを担当してます。その時に入力データは1画面につき10から100パラメーターになっていて、ホワイトボード代わりのハッシュに積んで、必須項目チェックをした上でディスプレイ用関数に渡しています。

    ディスプレイ用関数は初期状態で起動されるか、(必須項目のエラーなどから)入力画面を再描画するか、のために使われています。この関数は入力内容に従って、テキスト・ボックス、ラジオボタン、チェックボックス、プルダウン・リストを HTML タグ込みでレンダリングして、インハウスの HTML テンプレートに流し込まれて、結果画面をレンダリングします。

    つまり単純なパラメーター・テーブルから HTML 情報にまで展開することで、このディスプレイ関数は入出力しています。

    これまでの単体テストの実装の範囲で説明しますと、検算用に HTML でレンダリングされた基礎データを持たせて、入力に応じて "selected" や "checked" の属性を正規表現の置換を利用することで与えています。

    ですが、この手法だとパラメーター数の多い入力画面の処理で、かなり手間のかかるテスト関数の実装が要求されてしまいます。

    これまでの試行錯誤の上で、もっと自社製の HTML テンプレートのマクロを利用することで、ディスプレイ関数から HTML 情報を追い出してやることが可能なのではないか、と推測しています。そのようにすれば、もっと単純な入出力の比較で作業ができるのではないか、と。


    このようなことを踏まえて、Web アプリの場合の関数の粒度や入出力に対する実装例や提言などをお示しいただければ、と存じます。
  • id:KUROX
    「設定」->「設計」
    「検地」->「検出」
    夜寝ぼけて書いたようでいっぱい誤字脱字ありますね。
  • id:renpoo
    > KUROX さん

    おつかれさまです。ちゃんと文脈は伝わってきたと思うので御安心を。


    ちょっと考えたんですが、プルダウンのような入力項目を HTML に展開しなければならないのであれば、その1項目だけに特化した関数に分割してしまえば、単体テストはラクですよね。

    現行システムをいきなりそこまで改修するのは困難ですが、プロジェクトの推移によっては大規模なリファクタリングが発生する(Factory Method に移行したい)ので、その時、抜本的に粒度を下げる努力をしてみるつもりです。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません