質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

PHPUnit

PHPUnitは、PHP向けのユニット・テスト向けフレームワークで、手動では手間のかかるテスト作業を自動化し、繰り返し実行することが可能です。

ユニットテスト

ユニットテストは、システムのテスト手法の一つで、個々のモジュールを対象としたテストの事を指します。対象のモジュールが要求や性能を満たしているか確認する為に実行します。

PhpStorm

PhpStormは、JetBrains社が提供しているPHP向けのIDEです。同社の製品であるWebStormの機能を内包しており、優秀なコード補完やコード分析など多彩な機能を備えています。

Q&A

解決済

4回答

3763閲覧

ユニットテストの保守・運用について

RyosukeMurai

総合スコア30

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

PHPUnit

PHPUnitは、PHP向けのユニット・テスト向けフレームワークで、手動では手間のかかるテスト作業を自動化し、繰り返し実行することが可能です。

ユニットテスト

ユニットテストは、システムのテスト手法の一つで、個々のモジュールを対象としたテストの事を指します。対象のモジュールが要求や性能を満たしているか確認する為に実行します。

PhpStorm

PhpStormは、JetBrains社が提供しているPHP向けのIDEです。同社の製品であるWebStormの機能を内包しており、優秀なコード補完やコード分析など多彩な機能を備えています。

0グッド

8クリップ

投稿2015/05/26 01:27

はじめまして!
初めて投稿させていただきます、村井と申します。
よろしくお願い致します。

早速具体的な質問になりますが、
現在プロジェクトでユニットテストを組み込んで開発しようとしております。

ところが、
・ユニットテストの作成が大変
・作ったユニットテストをしょっちゅう修正しないといけない
・プログラムがとても複雑なので、ユニットテストで網羅するのが異常に大変

という課題に直面しています。
そもそものプログラムの質にも問題があると思っているのですが、
皆様はどのように運用されているか知りたく、質問させていただきました。

ご回答いただきたいことは下記の通りです。

1.メソッド1つに対するユニットテストの作成には、実装の何割程度の工数が必要でしょうか?(もちろんモノによるとは思いますが)

2.ユニットテストで網羅できる処理はシステム全体の何%程度を維持しておられるのでしょうか。逆に、何%を超えれば実用性があるとお考えでしょうか?

3.システムにおけるユニットテストの存在はもはや当たり前のような風潮を感じるのですが、個人的にはめちゃめちゃ大変な印象です。
皆様めちゃめちゃ大変な思いをしながら、それでも何とかがんばっておられるのでしょうか?

以上、ご確認よろしくお願い致します。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答4

0

ベストアンサー

■メソッド1つに対するユニットテストの作成には、実装の何割程度の工数が必要でしょうか?

メソッド1つの実装時間を算出した経験はなく、また必要性も感じないため、正確な数値ではありませんが、メソッド実装時間の半分ぐらいを見込んでおけば十分ではないでしょうか。

個人的には、メソッド1つではなく、クラス1個を最小単位とすべきかと思います。

■ユニットテストで網羅できる処理はシステム全体の何%程度を維持しておられるのでしょうか。

どのようなプログラム設計をしているのか定かではないので正確な回答にはなりませんが、一般的なMVCアーキテクチャのWEBアプリケーションであれば、Model層のモジュールとDBアクセス関連のモジュールに関しては100%を維持すべきかと思います。恐らくはこれが最低限になるかと思います。

Controller層やView層については、ユニットテストは不可能ではないのですが、実際に動作させてブラウザで確認した方が早いことが多いので、個人的にはあまり重要視していません。

■システムにおけるユニットテストの存在はもはや当たり前のような風潮を感じるのですが、個人的にはめちゃめちゃ大変な印象です。

ユニットテストのメリットは、一度テストコードを書けば何度でも実行可能な点にあります。テストコードを自動的に実行する仕組みを構築しておけば、コードが変更されるたびに回帰テストを行うことができます。

これをユニットテストなしに、実際にプログラムを動かして動作チェックを行うほうが大変だと思います。

もちろん、実際にプログラムを操作してテストすることは必要ではありますが、それを減らせることは大きなメリットであると思います。

テストコードの作成が非常に困難である場合は、どちらかというとプログラムの設計に問題がある場合が多いように思われます。

適切なクラス設計はされているか、テストが容易な設計になっているかを確認してもよいかもしれません。

投稿2015/05/26 02:02

編集2015/05/26 02:14
退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

RyosukeMurai

2015/05/26 03:11

ご丁寧なご回答ありがとうございます! メソッドのIO定義自体が曖昧なまま開発を進めているので、テスト範囲が非常に膨大になっているのだと思います。 やはり事前の設計をキッチリすることで、テストの作成も容易になるのでしょうね・・・。根本問題はそこにある気がしてきました。 ちなみに、ユニットテストがきちんと回るとバグの発生率はやはり下がっていくものでしょうか?コストに見合うメリットが出せるかどうかも考えておりまして。 曖昧な質問で申し訳ないのですが、フィーリングで結構ですのでご回答頂ければ幸いです。
退会済みユーザー

退会済みユーザー

2015/05/26 03:57

>ユニットテストがきちんと回るとバグの発生率はやはり下がっていくものでしょうか? もちろん下がります。 実装しながらモジュール単位で動作確認ができることになりますので、コーディング時のミスに由来するバグは実装段階でほぼ潰せます。 したがって、いわゆる結合試験以降で、「引数が間違っていたため実行時エラー」「変数の代入ミスでエラー」的な低レベルな不具合は減少します。 ただし、仕様の考慮漏れや要件漏れなどのより上流フェーズ由来のバグはユニットテストでは検知できないので、そのような不具合の発生率はユニットテストを導入しても変化はありません。
RyosukeMurai

2015/05/26 15:03

ありがとうございます。 結論的にはデータフローの整理、設計をキッチリ行い、 モジュールの毎の処理の定義、IOの定義を行うことで、 テストが出来るコードになっていくのだと理解できました。 上流については、運用テスト、ブラックボックステストなどでつぶしていくイメージなのでしょうね。 このあたりは、システムで求められる品質レベルとも相談していきながら検討していきます。 長々とお付き合いいただきありがとうございました。
guest

0

テスト駆動開発には、「テストの声を聞く」という言葉があります。簡単にいえば、「容易にテストを書けないようなコードは、コード自体の性質が良くない」ということです。

1つの関数であれこれ実行するとなると、それに比例してテストも複雑怪奇化していきますので、テスト作成自体が困難になってきます。そういうタイミングでコードをリファクタリングするというのが、テスト駆動開発の趣旨の1つです。

なお、他のモジュールに依存するモジュールについても、適当な動作をするテスト専用のモジュールを用意することで、ほかと分離してユニットテストできるようになります。

投稿2015/05/26 04:32

編集2015/05/26 04:33
maisumakun

総合スコア145121

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

RyosukeMurai

2015/05/26 15:05

なるほど。ユニットテストのノウハウが溜まっていくんですね。 やはり、fat過ぎるコントローラーの存在は薄々気付いていて、結局はそこが問題になっているわけですよね。テストファーストが成り立つ設計をまずは意識して行こうと思います。
guest

0

1.メソッド1つに対するユニットテストの作成には、実装の何割程度の工数が必要でしょうか?(もちろんモノによるとは思いますが)

1~2倍という人もいれば2~5倍という人もいます。
少なくとも実装の工数よりはかかると考えておくべきだと思います。

2.ユニットテストで網羅できる処理はシステム全体の何%程度を維持しておられるのでしょうか。逆に、何%を超えれば実用性があるとお考えでしょうか?

結合テストとの兼ね合いやコスト、システムの構成などで大きく変わるので何%までなどとはいえないと考えます。
たとえ数パーセントのユニットテストが特に有効な箇所に対してのみ適用するというのも一つの方法だと思います。

3.システムにおけるユニットテストの存在はもはや当たり前のような風潮を感じるのですが、個人的にはめちゃめちゃ大変な印象です。
皆様めちゃめちゃ大変な思いをしながら、それでも何とかがんばっておられるのでしょうか?

ユニットテストを作る時に苦労するか、後の改修やリファクタリング時に何度も苦労するか。
現在のシステム開発は(ユニットテストを作る時に苦労)<(改修やリファクタリング時に何度も苦労)な傾向のプロジェクトが多くなっているのでユニットテストの存在感が強くなっているように感じます。

追記:

・ユニットテストの作成が大変

後で楽するためです

・作ったユニットテストをしょっちゅう修正しないといけない

takotakotさんと同様にどういう状況なのかと思ってしまいます。

・プログラムがとても複雑なので、ユニットテストで網羅するのが異常に大変

メソッドの粒度が粗過ぎるのでは?

投稿2015/05/26 02:56

編集2015/05/26 03:01
sho_cs

総合スコア3541

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

RyosukeMurai

2015/05/26 03:02

ありがとうございます!端的で分かりやすいです。 やはりある程度ユニットテストの作成にコストはかかるということですよね。 プロジェクトでそこの見込みが甘いので、上手く回っていないのかもしれません。
RyosukeMurai

2015/05/26 03:03

メソッドの粒度はご指摘の通りだと思います。 100行を超えるメソッドもザラにあり、メソッド内で別クラスのメソッドを呼び出し、switchで分岐し、と非常に複雑化しているため、テストの作成が困難になっていると自覚しました。
guest

0

「作ったユニットテストをしょっちゅう修正しないといけない」理由が知りたいです。
どういう状況で使われているのか…
テスト駆動開発という開発がありますが、それでは「ユニットテストを定義して、それに合うようにコードを書く」という流れで開発が行われます。テストの方を変えるということは、仕様が変わるということで、なにかおかしいのではないでしょうか。

以下追記
「今後ユニットテストが変わらない」ように、小さくメソッドを切り出し、ユニットテストを書く、というリファクタリングをすれば、多くのメソッドを小さく、かつ、保守性のある形にできそうですね。仕様変更等で、どうしても書き換えないといけない関数を減らしていくのが目標です。

投稿2015/05/26 02:31

編集2015/05/26 03:28
takotakot

総合スコア1111

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

RyosukeMurai

2015/05/26 03:07

テスト駆動開発ですか・・・。アジャイルしかり、聞くことはあるのですが、会社の業務フローを大きく変えて導入するビジョンが見えておらず・・・。皆様ある日突然テスト駆動にしようぜ!っていって進めるものなんでしょうか。 たぶんウチのフローはいろいろと未熟だと思います・・・。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問