C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[4]: TDDの単体テスト仕様書について

(過去ログ 69 を表示中)

[トピック内 20 記事 (1 - 20 表示)]　 << 0 >>

■40320 / inTopicNo.1)

　TDDの単体テスト仕様書について

▼■

□投稿者/ TDD初心者 (1回)-(2009/08/24(Mon) 09:08:52)

分類:[.NET 全般]　

初めまして。質問させてくださいm(_ _)m

私は今まで、単体テストをする際、
単体テスト仕様書＋単体テスト結果（エビデンス）を作成してきました。

しかし、この成果物は非常に労力の無駄（書く方もチェックする方も）になると思っています。
仕様変更→ソース修正→単体テスト仕様書修正→エビデンス修正
また、見栄えがいいように作成してほしい等、不要な注文もあります。

そこでTDDを取り入れると、
テスト仕様書、テスト結果が不要になる可能性はあるのでしょうか？

引用返信 編集キー/

■40322 / inTopicNo.2)

　Re[1]: TDDの単体テスト仕様書について

▲▼■

□投稿者/ .SHO (1023回)-(2009/08/24(Mon) 09:30:26)

> また、見栄えがいいように作成してほしい等、不要な注文もあります。
>
> そこでTDDを取り入れると、
> テスト仕様書、テスト結果が不要になる可能性はあるのでしょうか？

『見栄えがいいように作成してほしい』という要求があるということは
そのドキュメントは業務として（？）必要なんでしょうから
不要になることはないです。

せめて無駄にならないように作成することを心がけた方が良いと思います。

引用返信 編集キー/

■40323 / inTopicNo.3)

　Re[1]: TDDの単体テスト仕様書について

▲▼■

□投稿者/ kzt (1回)-(2009/08/24(Mon) 09:40:57)

> そこでTDDを取り入れると、
> テスト仕様書、テスト結果が不要になる可能性はあるのでしょうか？

これはまず無いのではないでしょうか？
そもそもTDDを取り入れる事がどのような事なのか？です。
テスト仕様書やテスト結果を無くす為の手法ではないと思います。

> また、見栄えがいいように作成してほしい等、不要な注文もあります。

どうして不要な注文なのでしょうか？
お客様として、見やすくそして見栄えが良い物を必要とするのは当然ではないでしょうか？
あくまでも設計書はお客様からの視点から言うとどのような成果物、結果を出したかを確認する物であり、TDDを取り入れようと単体テスト自動化を取り入れようが関係ないはずです。
お客様からすればTDDなどは関係無い訳ですから・・。

#テストケースをSandCastle等で生成し.chm形式で納品可能であったりすれば、工夫すれば単体テスト仕様書として成り立つかもしれませんが。

引用返信 編集キー/

■40327 / inTopicNo.4)

　Re[2]: TDDの単体テスト仕様書について

▲▼■

□投稿者/ TDD初心者 (2回)-(2009/08/24(Mon) 10:31:14)

■No40322 (.SHO さん) に返信
■No40323 (kzt さん) に返信
少し語弊（説明不足）がありました。

現在、私はその「お客様」側です。

私はその「お客様」として、単体テスト仕様書、単体テスト結果は不要なものと判断したいわけです。
単体テストとは、あくまで開発作業の一部として認識すべきものであり、
その単体テスト工程は、テストを自動化することによって、仕様書、結果を作成する労力を、
よりアプリケーションに注ぐべきものと考えております。

また、そのテストを自動化することによって、ソースの複雑度や、カバレッジ分析を採取するツールもあります。
これらを、抽出し管理することによって、この単体テスト仕様書、単体テスト結果を無くすことはできないだろうか？
と考えております。

不要だと考えている理由としては、以下のような理由（そういった担当者がいる）からです。
・特に見る機会が無い
・細部まで検証せず、OKと判断している
・ただ、ドキュメントが多いと満足している
・開発→単体テスト仕様書、結果作成→仕様変更→単体テスト仕様書、結果の修正は不要としている人がいる
などなど･･･。

※しかし、2005年くらいの情報でしたが、TDDでは主にビジネスロジックを中心としたものであり、
GUIのテスト(コントロールの桁数制御等)はできないとWebで拝見しました。

以上が、大雑把ですが、
>テスト仕様書、テスト結果が不要になる可能性はあるのでしょうか？
の質問内容となります。

よろしくおねがいします。
※ざっと書きましたので、意味わかんない！という突っ込み歓迎です。

引用返信 編集キー/

■40330 / inTopicNo.5)

　Re[3]: TDDの単体テスト仕様書について

▲▼■

□投稿者/ kzt (2回)-(2009/08/24(Mon) 11:08:23)

TDDとはいえども結局はプログラムを組む訳ですから、そのプログラムに対してのドキュメントはどうされますか？
「お客様」側として、作成された単体テストプログラムをドキュメントなしに理解する事が出来るのであれば「お客様」側としての判断は色々行えるかと思いますが、現実そうはいかないと考えます。

> その単体テスト工程は、テストを自動化することによって、仕様書、結果を作成する労力を、
> よりアプリケーションに注ぐべきものと考えております。

これは理想ではありますが、熟練したTDDの実施経験、それをプロジェクトに導入する際の開発手法などによっても、TDDを取り入れたからアプリケーションに注ぐ時間に充てられるか？とは一概に言えないと思います。
またTDDを取り入れても単体テスト自動化をしているプログラムの実装方法によっては保守に掛る工数も変わってくると思います。仕様変更に柔軟に対応しているプログラムか？などです。
TDDを取り入れても今までのプロセス以上の工数が掛る要因はあるわけで・・。
TDDをピンポイントに見るだけではなくどのようにプロジェクトにTDDを取り入れ、時間を効率的に使用出来るか？というのがとても重要だと私は思います。

引用返信 編集キー/

■40332 / inTopicNo.6)

　Re[3]: TDDの単体テスト仕様書について

▲▼■

□投稿者/ .SHO (1024回)-(2009/08/24(Mon) 11:26:36)

> 私はその「お客様」として、単体テスト仕様書、単体テスト結果は不要なものと判断したいわけです。

なるほど。

可能性があるかないかで答えるなら、あるでしょうね。
絶対にないとは言えないです。

ただ、客先が開発にそこまで突っ込むことは通常はないんじゃないかな？
もし、そのコストが直接、購入価格に大きく影響しているなら
交渉の余地はありそうです。
（客先から見て）明らかに無駄なものを作成しているわけですから。

引用返信 編集キー/

■40335 / inTopicNo.7)

　Re[4]: TDDの単体テスト仕様書について

▲▼■

□投稿者/ .SHO (1025回)-(2009/08/24(Mon) 11:47:59)

> 可能性があるかないかで答えるなら、あるでしょうね。
> 絶対にないとは言えないです。

誤解があるとアレなんで、追記しておきますが
TDDにすれば可能性があると言っているわけではないです。

> ・特に見る機会が無い
> ・細部まで検証せず、OKと判断している
> ・ただ、ドキュメントが多いと満足している
> ・開発→単体テスト仕様書、結果作成→仕様変更→単体テスト仕様書、結果の修正は不要としている人がいる
> などなど･･･。

が、事実だとして、無駄ならば作る必要ないですね。

TDDにすることと単体テスト仕様書をなくすことに関連性はないです。

引用返信 編集キー/

■40338 / inTopicNo.8)

　Re[4]: TDDの単体テスト仕様書について

▲▼■

□投稿者/ なぎせゆうき (1回)-(2009/08/24(Mon) 11:54:29)

よく混同される点ではありますが、TDDのテストは実装のためのテストであって、品質ホショウ（スパムキーワードにひっかかるようなのでカタカナ）のテストとは別物ですよ。

TDDのためのテストにテスト仕様書、テスト結果を必要としていたらTDDは回りません。
TDDではまずテストを書き、自動テストをレッドにして、初めてソースコードを書くことができます。
そしてグリーンにしてからリファクタリングをします。駆動のためのテストなので、目の前の必要なことを
必要なだけ、相当の割り切りを持って書くことがTDDを回すコツです。

なので、最初から品質ホショウのテストのように境界値テストを網羅したりとかはしません。
TDDのテストは作る過程そのもので、網羅的なテストではないわけですから、それをそのまま品質ホショウのためのテストとして提出することもできません。
TDDの際に作った自動テストを品質ホショウのためのテストとして流用することは可能ですが、その際に境界値テストを網羅するなどを手を加える必要があります。
こうして、必要な項目を網羅する自動テストに組み直すのであれば、それはTDDのテストとは別物に仕上がります。TDD用のテストプロジェクトと品質ホショウ用の自動テストは別プロジェクトで管理するべきです。
そして、品質ホショウ用の自動テストにはどのようなテストを網羅したのかの書類を添付します。

引用返信 編集キー/

■40340 / inTopicNo.9)

　Re[1]: TDDの単体テスト仕様書について

▲▼■

□投稿者/ Jitta on the way (406回)-(2009/08/24(Mon) 12:07:22)

■No40320 (TDD初心者さん) に返信

> そこでTDDを取り入れると、
> テスト仕様書、テスト結果が不要になる可能性はあるのでしょうか？
>

ない、でしょう。
受け入れ検査をどの様にするかによって、総合的に品質を確保させることで、納品対象から単体テストを省くことが出来るかも知れません。
また、単体テスト（だけでなく結合くらいまでいけそうだけど）を自動実行できるように構成することで、単体テストはそのままに、かかる手間を削減することが出来そうです。

引用返信 編集キー/

■40341 / inTopicNo.10)

　Re[4]: TDDの単体テスト仕様書について

▲▼■

□投稿者/ biac (158回)-(2009/08/24(Mon) 12:08:29)

え～と…
議論が発散する前に f(^^;

「単体テスト」の意味というか、テスト対象の粒度をある程度明らかにしておいたほうがよいかと。
TDD を実践しているものにとっては「単体テスト」 = 「基本はメソッドひとつに対するテスト」ですが、人によって「画面ひとつ」だったり、「機能ひとつ」、「プログラムひとつ」だったりします。

また、今の xUnit 前提の TDD ではメソッド単位ですが、画面のテストも自動実行可能になってきており、 (TDD と言うにはサイクルタイムが長いので、別の名前を考えないといけないかもしれませんが) 画面もテストファーストで作れる条件が整いつつあります。自動化テストも、 xUnit のコードを直接書く方法が唯一の手段ではありませんし。そういった自動化されたテスト技術の進歩も、考慮するべきなのかもしれませんよ。たとえば、 Excel のシートで画面のテストケースが表現できて、そのテストが自動実行できるようになったと仮定してみてください。自動実行させるために書式の制約などが付くでしょうから、ちょっと読みにくいと思いますが、顧客サイドでもなんとか読みこなせるような画面単位のテストケース (と、自動テストした結果) が Excel ファイルで提供できるようになったとしたら…?

・現状の xUnit を前提とした TDD で、「○○テスト」の仕様書は不要になるだろうか?
・「××テスト」を△△のようなカタチで自動化できれば、「××テスト」の仕様書は不要になるだろうか?

引用返信 編集キー/

■40342 / inTopicNo.11)

　Re[4]: TDDの単体テスト仕様書について

▲▼■

□投稿者/ TDD初心者 (3回)-(2009/08/24(Mon) 12:11:18)

■No40330 (kzt さん) に返信
> TDDとはいえども結局はプログラムを組む訳ですから、そのプログラムに対してのドキュメントはどうされますか？
> 「お客様」側として、作成された単体テストプログラムをドキュメントなしに理解する事が出来るのであれば「お客様」側としての判断は色々行えるかと思いますが、現実そうはいかないと考えます。
「お客様」側として、作成された単体テストプログラムをドキュメントなしに理解する事は"必要ない"と私は思います。
ただ、そういう仕組みが実装されているという事実が欲しいだけです。
現実と理想のギャップはあるかもしれませんが、常に改善できるシステムが理想であり、
その布石として、リファクタリングが自由に行えるTDDはメリットがあると考えます。
そして、そこにドキュメントなるものは"必要ない"はずです(たぶん)。
あくまで、プログラムがドキュメント(仕様)であり、そのメンテナンスはプログラマーだからです。
ただ、アーキテクトなるドキュメントは欲しいときもあるかと思いますが･･･。

>>その単体テスト工程は、テストを自動化することによって、仕様書、結果を作成する労力を、
>>よりアプリケーションに注ぐべきものと考えております。
>
> これは理想ではありますが、熟練したTDDの実施経験、それをプロジェクトに導入する際の開発手法などによっても、TDDを取り入れたからアプリケーションに注ぐ時間に充てられるか？とは一概に言えないと思います。
> またTDDを取り入れても単体テスト自動化をしているプログラムの実装方法によっては保守に掛る工数も変わってくると思います。仕様変更に柔軟に対応しているプログラムか？などです。
> TDDを取り入れても今までのプロセス以上の工数が掛る要因はあるわけで・・。
> TDDをピンポイントに見るだけではなくどのようにプロジェクトにTDDを取り入れ、時間を効率的に使用出来るか？というのがとても重要だと私は思います。
開発者として、単体テスト仕様書、結果を作成する労力と、テストプログラムを実装する労力はどちらが好ましいでしょうか？
テストプログラム側での単体テスト結果は、複雑度や、カバレッジ分析を抽出して頂きますが。

■No40332 (.SHO さん) に返信
>>私はその「お客様」として、単体テスト仕様書、単体テスト結果は不要なものと判断したいわけです。
>
> なるほど。
>
> 可能性があるかないかで答えるなら、あるでしょうね。
> 絶対にないとは言えないです。
問題は、GUI部分のビジネスロジックとは関係のない、
動的に変わるチェックロジックや、桁数制限、または、動的に変わる見た目をどうやって、
TDDで実現するか？というところでしょうか？
見た目は我々の「目視」ということでしょうかね。。

> ただ、客先が開発にそこまで突っ込むことは通常はないんじゃないかな？
はい、通常はないと思います。
ただ客先として、その分からない部分は業者にというスタンスは私は嫌いなので･･･。
> もし、そのコストが直接、購入価格に大きく影響しているなら
> 交渉の余地はありそうです。
> （客先から見て）明らかに無駄なものを作成しているわけですから。
はい、その視点もあります。
我々客先にはそのような成果物は必要ありませんが、
ドキュメントが多ければいいという風潮もないと言えば、嘘になるのが現実です。
そのようなものに対して、お金を出すのは「無駄」です。

引用返信 編集キー/

■40347 / inTopicNo.12)

　Re[5]: TDDの単体テスト仕様書について

▲▼■

□投稿者/ TDD初心者 (4回)-(2009/08/24(Mon) 12:36:16)

■No40338 (なぎせゆうきさん) に返信
> よく混同される点ではありますが、TDDのテストは実装のためのテストであって、品質ホショウ（スパムキーワードにひっかかるようなのでカタカナ）のテストとは別物ですよ。
なるほど、
TDD用･･･開発者用
品質ホショウ用･･･客先用
それぞれのテストプログラムが必要になるということですか。
開発工数もかなり膨れ上がりそうですね。

引用返信 編集キー/

■40348 / inTopicNo.13)

　Re[5]: TDDの単体テスト仕様書について

▲▼■

□投稿者/ biac (159回)-(2009/08/24(Mon) 12:49:01)

■No40342 (TDD初心者さん) に返信
> 問題は、GUI部分のビジネスロジックとは関係のない、
> 動的に変わるチェックロジックや、桁数制限、または、動的に変わる見た目をどうやって、
> TDDで実現するか？というところでしょうか？
> 見た目は我々の「目視」ということでしょうかね。。

GUI 部分の自動化テストの現状 (ごく一部)

・ Excel マクロ + selenium の試み (表形式の仕様書から、自動化テストを生成)
　 http://codezine.jp/article/detail/2345

・ VS2010 の Coded UI Test (xUnit と同様のテストコードを書く)
　 http://bluewatersoft.cocolog-nifty.com/blog/2009/01/vs2010-gui-7ca5.html

いずれも画面のテストの全てを自動化できるわけではないでしょうし、「Excel マクロ + …」の方は、レッド (テストの記述とテスト失敗の確認) → グリーン (実装コードの記述とテスト成功の確認) のサイクルタイムが数分で収まるとは思えないので、 TDD と呼びにくいです。

このように、画面単位の単体テストも、自動化テストで行えるようになってきているので、 (TDD とは違うかもしれませんが) 自動化テスト作成 → 実装 → 自動テストという流れで作業することは不可能ではなくなってきています。

引用返信 編集キー/

■40349 / inTopicNo.14)

　Re[5]: TDDの単体テスト仕様書について

▲▼■

□投稿者/ TDD初心者 (5回)-(2009/08/24(Mon) 12:51:19)

■No40341 (biac さん) に返信
> 「単体テスト」の意味というか、テスト対象の粒度をある程度明らかにしておいたほうがよいかと。
> TDD を実践しているものにとっては「単体テスト」 = 「基本はメソッドひとつに対するテスト」ですが、人によって「画面ひとつ」だったり、「機能ひとつ」、「プログラムひとつ」だったりします。
なるほど、人によって粒度が異なるわけですか。
その粒度は定義してやる必要がありそうですね。
私が考えているのは、「メソッドひとつに対するテスト」と言いたいところですが、
網羅率が高ければ、「画面ひとつ」だったり、「機能ひとつ」、「プログラムひとつ」もよいかと思います。
ちなみにビヘイビア駆動開発というのもあるのですね。
この場合は、「メソッド単位」でのテストはあまりなさそうに感じますが、いかがでしょうか？

引用返信 編集キー/

■40352 / inTopicNo.15)

　Re[2]: TDDの単体テスト仕様書について

▲▼■

□投稿者/ ふくちゃん (52回)-(2009/08/24(Mon) 13:15:56)

うちはテスト仕様書がエクセル形式になっており、
そのエクセルファイルをテスト用アプリが読み込み
結果が想定通りになっているかを表示する形にしています。

仕様書さえきっちり作ってしまえば、テストアプリ開発、結果書き込みなどの
手間が省ける方法ですね。

引用返信 編集キー/

■40353 / inTopicNo.16)

　Re[3]: TDDの単体テスト仕様書について

▲▼■

□投稿者/ TDD初心者 (7回)-(2009/08/24(Mon) 13:26:24)

■No40352 (ふくちゃんさん) に返信
> うちはテスト仕様書がエクセル形式になっており、
> そのエクセルファイルをテスト用アプリが読み込み
> 結果が想定通りになっているかを表示する形にしています。
>
>
> 仕様書さえきっちり作ってしまえば、テストアプリ開発、結果書き込みなどの
> 手間が省ける方法ですね。
ものすごいExcel＋テスト用アプリですね。
理想なんじゃないですか？
ちなみに、運用してみてのデメリットをお聞かせ頂けるとありがたいです。

引用返信 編集キー/

■40355 / inTopicNo.17)

　Re[6]: TDDの単体テスト仕様書について

▲▼■

□投稿者/ TDD初心者 (8回)-(2009/08/24(Mon) 13:29:30)

■No40348 (biac さん) に返信
> GUI 部分の自動化テストの現状 (ごく一部)
>
> ・ Excel マクロ + selenium の試み (表形式の仕様書から、自動化テストを生成)
> 　 http://codezine.jp/article/detail/2345
こちらはよく分かりませんでしたorz

> ・ VS2010 の Coded UI Test (xUnit と同様のテストコードを書く)
> 　 http://bluewatersoft.cocolog-nifty.com/blog/2009/01/vs2010-gui-7ca5.html
こちらから、UIオートメーションなる技術も最近出てきているようですが、
プログラムが難しそうですね。それなりの知識、技術力が要求されそうです。
しかし、不可能ではないということですね。勉強になりました。

引用返信 編集キー/

■40356 / inTopicNo.18)

　Re[6]: TDDの単体テスト仕様書について

▲▼■

□投稿者/ biac (160回)-(2009/08/24(Mon) 13:37:19)

2009/08/24(Mon) 14:04:16 編集(投稿者)
2009/08/24(Mon) 14:03:12 編集(投稿者)

■No40349 (TDD初心者さん) に返信
> ■No40341 (biac さん) に返信
>>「単体テスト」の意味というか、テスト対象の粒度をある程度明らかにしておいたほうがよいかと。
>>TDD を実践しているものにとっては「単体テスト」 = 「基本はメソッドひとつに対するテスト」ですが、人によって「画面ひとつ」だったり、「機能ひとつ」、「プログラムひとつ」だったりします。
> なるほど、人によって粒度が異なるわけですか。
> その粒度は定義してやる必要がありそうですね。
> 私が考えているのは、「メソッドひとつに対するテスト」と言いたいところですが、
> 網羅率が高ければ、「画面ひとつ」だったり、「機能ひとつ」、「プログラムひとつ」もよいかと思います。

xUnit だけを使うのが前提の現在の TDD では、『「画面ひとつ」だったり、「機能ひとつ」、「プログラムひとつ」』のテストは TDD の範疇外です。いちおう念の為。

> ちなみにビヘイビア駆動開発というのもあるのですね。
> この場合は、「メソッド単位」でのテストはあまりなさそうに感じますが、いかがでしょうか？

BDD も、ごく小さなふるまいから始めて、複雑なふるまいへと進めていくと思います。 ( 実際にやったことはないので、想像ですけれど。でも、ユーザー視点のユースケースを、いきなり BDD のストーリー/シナリオとして記述し始めるとは思えない。)
で、ごく小さなストーリー/シナリオでは、 TDD のテストと大差ありません。

ごくシンプルなサンプルを、 BDD と Visual Studio の単体テストの両方で示してみましたので、ご参考までに。
→ http://www.tdd-net.jp/2009/08/bdd---dan-north.html
※ この例の BDD のテストでは、そのテスト対象は「Account オブジェクト間で、お金を transfer するというふるまい」です。実装で言えば、 Account クラスの TransferTo() メソッドです。なお、 TransferTo() メソッドをテストするために、 Balance プロパティを見る必要があります。

引用返信 編集キー/

■40363 / inTopicNo.19)

　Re[7]: TDDの単体テスト仕様書について

▲▼■

□投稿者/ TDD初心者 (9回)-(2009/08/24(Mon) 14:30:00)

■No40356 (biac さん) に返信
>>ちなみにビヘイビア駆動開発というのもあるのですね。
>>この場合は、「メソッド単位」でのテストはあまりなさそうに感じますが、いかがでしょうか？
>
> BDD も、ごく小さなふるまいから始めて、複雑なふるまいへと進めていくと思います。 ( 実際にやったことはないので、想像ですけれど。でも、ユーザー視点のユースケースを、いきなり BDD のストーリー/シナリオとして記述し始めるとは思えない。)
> で、ごく小さなストーリー/シナリオでは、 TDD のテストと大差ありません。
>
> ごくシンプルなサンプルを、 BDD と Visual Studio の単体テストの両方で示してみましたので、ご参考までに。
> → http://www.tdd-net.jp/2009/08/bdd---dan-north.html
> ※ この例の BDD のテストでは、そのテスト対象は「Account オブジェクト間で、お金を transfer するというふるまい」です。実装で言えば、 Account クラスの TransferTo() メソッドです。なお、 TransferTo() メソッドをテストするために、 Balance プロパティを見る必要があります。
参考になります。ありがとうございます。
BDDは、開発に近い人間と顧客に近い人間、もしくは顧客間との曖昧な語句の統一を図る術としても魅力的ですね。
こちらも勉強していきたいと思います。

引用返信 編集キー/

■40364 / inTopicNo.20)

　Re[4]: TDDの単体テスト仕様書について

▲　■

□投稿者/ TDD初心者 (10回)-(2009/08/24(Mon) 14:32:24)

皆様と議論しているうちに、
単体テスト仕様書は必要に思えるようになってきました。
(テスト結果は別してですが。)

では、TDDを組み入れて、
どのようなテスト仕様書が望ましいのか、考案していきたいと思います。

解決済みとさせて頂きます。
ありがとうございました。

解決済み

引用返信 編集キー/

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

- Child Tree -