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

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

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

Re[4]: テストファーストではないTDD

(過去ログ 74 を表示中)

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

■43163 / inTopicNo.1)

　テストファーストではないTDD

▼■

□投稿者/ kyo (1回)-(2009/10/30(Fri) 11:56:14)

分類:[設計/仕様]　

お世話になります。

TDDについて疑問があります。

TDDとは、テストファーストを行うスタイルだと、Wikipediaで読みました。
http://ja.wikipedia.org/wiki/%E3%83%86%E3%82%B9%E3%83%88%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA

---引用
テスト駆動開発 (test-driven development; TDD) とは、プログラム開発手法の一種で、プログラム本体よりも先にテストケースを書くスタイルである。このスタイルをテストファーストともいう。多くのアジャイルソフトウェア開発手法、例えばエクストリーム・プログラミングにおいて強く推奨されている。近年はビヘイビア駆動開発へと発展を遂げている。

では、テストファーストではないスタイルはなんというのでしょうか？

メソッドを先に書いて、そのテストを書く、
あるいは、メソッドを作成しながら、そのテストも作成する。
といったスタイルもTDDと呼ぶのでしょうか？

引用返信 編集キー/

■43165 / inTopicNo.2)

　Re[1]: テストファーストではないTDD

▲▼■

□投稿者/ かずき (51回)-(2009/10/30(Fri) 12:31:22)

■No43163 (kyo さん) に返信
> メソッドを先に書いて、そのテストを書く、
> あるいは、メソッドを作成しながら、そのテストも作成する。
> といったスタイルもTDDと呼ぶのでしょうか？
個人的には、気持ちの問題かなぁと思います。
単体テストに重きを置いてる（テスト駆動）なのか、そうでないのか。

引用返信 編集キー/

■43166 / inTopicNo.3)

　Re[2]: テストファーストではないTDD

▲▼■

□投稿者/ kyo (3回)-(2009/10/30(Fri) 12:38:03)

コメントありがとうございます。

■No43165 (かずきさん) に返信
> ■No43163 (kyo さん) に返信
>>メソッドを先に書いて、そのテストを書く、
>>あるいは、メソッドを作成しながら、そのテストも作成する。
>>といったスタイルもTDDと呼ぶのでしょうか？
> 個人的には、気持ちの問題かなぁと思います。
> 単体テストに重きを置いてる（テスト駆動）なのか、そうでないのか。

Visual Studio 2008 Development Editionでは、
単体テストを生成する際、テスト、メソッドのどちら側からでも生成できるように設定されています。

メソッドから作成した場合は、
「TDDで開発してます。」と言い切れるのか？と疑問に思ったまでです。
「テストファーストでないTDDで開発してます。」というのも、矛盾が生じる気がします。

こういった場合、「テストを自動化してます。」というべきなんでしょうか？

引用返信 編集キー/

■43181 / inTopicNo.4)

　Re[3]: テストファーストではないTDD

▲▼■

□投稿者/ なぎせゆうき (4回)-(2009/10/30(Fri) 17:52:48)

>>■No43163 (kyo さん) に返信
>
> こういった場合、「テストを自動化してます。」というべきなんでしょうか？

TDDはテストドリブン、テスト駆動ですよね。
自動テストを先に書くだけだと単なるテストファーストです。
テストが開発の駆動力になって初めてTDDではないでしょうか。

引用返信 編集キー/

■43184 / inTopicNo.5)

　Re[4]: テストファーストではないTDD

▲▼■

□投稿者/ まりも (3回)-(2009/10/30(Fri) 22:53:16)

テスト駆動開発をやる時は、
テストを書いたのちに、
テストを通すためにのみコードを書き、
テストによる検証を繰り返しながらリファクタリングをします。

まさにテストで駆動している感じです。
だからテスト駆動開発というんじゃないでしょうか。

引用返信 編集キー/

■43194 / inTopicNo.6)

　Re[4]: テストファーストではないTDD

▲▼■

□投稿者/ kyo (4回)-(2009/10/31(Sat) 14:04:24)

コメントありがとうございます

■No43181 (なぎせゆうきさん) に返信
> >>■No43163 (kyo さん) に返信
> >
>>こういった場合、「テストを自動化してます。」というべきなんでしょうか？
>
> TDDはテストドリブン、テスト駆動ですよね。
> 自動テストを先に書くだけだと単なるテストファーストです。
> テストが開発の駆動力になって初めてTDDではないでしょうか。

では、テストファーストであろうがなかろうが、
自動テストで、開発を駆動させていく方針がTDDであるというお考えでしょうか？
私もそのように思います。

引用返信 編集キー/

■43196 / inTopicNo.7)

　Re[5]: テストファーストではないTDD

▲▼■

□投稿者/ kyo (5回)-(2009/10/31(Sat) 14:10:35)

■No43184 (まりもさん) に返信
> テスト駆動開発をやる時は、
> テストを書いたのちに、
> テストを通すためにのみコードを書き、
> テストによる検証を繰り返しながらリファクタリングをします。
>
> まさにテストで駆動している感じです。
> だからテスト駆動開発というんじゃないでしょうか。

やはり、テストファーストであるからこそのTDDというお考えでしょうか？
テストファーストではない人には、「TDDです。」とは言えないということですね。

しかし、ここで疑問です。
メソッドも単体テストも完成してしまえば、テストファーストだったのか分かりません。
この状態を人はなんと呼ぶのでしょうか？

引用返信 編集キー/

■43197 / inTopicNo.8)

　Re[6]: テストファーストではないTDD

▲▼■

□投稿者/ επιστημη (2240回)-(2009/10/31(Sat) 14:29:26)

> メソッドも単体テストも完成してしまえば、テストファーストだったのか分かりません。
> この状態を人はなんと呼ぶのでしょうか？

「単体テストが完了した状態」じゃないすか。

引用返信 編集キー/

■43203 / inTopicNo.9)

　Re[6]: テストファーストではないTDD

▲▼■

□投稿者/ まりも (4回)-(2009/10/31(Sat) 19:07:49)

> やはり、テストファーストであるからこそのTDDというお考えでしょうか？
> テストファーストではない人には、「TDDです。」とは言えないということですね。

厳密にいえば、テストファーストではなくテスト駆動開発する方法がある可能性はありますが。
私は知らないし、想像もできない、ということですね。

> しかし、ここで疑問です。
> メソッドも単体テストも完成してしまえば、テストファーストだったのか分かりません。
> この状態を人はなんと呼ぶのでしょうか？

テスト駆動開発とは、どのようにして開発するか、という方法を表すものですから。
完成品がどのように呼ばれるかは、テスト駆動開発とは何の関係もないと思います。

別に完全なウォーターフォールでも、レビューなどきっちりやれば、
テスト駆動開発と同等のメソッド、自動単体テストを作ることはできると思います。
できたんだったら、それを区別する理由はないと思います。
たぶん工数が多くかかっているとは思いますが、それは完成品とは関係ない話です。

引用返信 編集キー/

■43212 / inTopicNo.10)

　Re[7]: テストファーストではないTDD

▲▼■

□投稿者/ kyo (6回)-(2009/11/02(Mon) 11:05:37)

コメントありがとうございます。

■No43197 (επιστημη さん) に返信
>「単体テストが完了した状態」じゃないすか。
■No43203 (まりもさん) に返信
>テスト駆動開発とは、どのようにして開発するか、という方法を表すものですから。
>完成品がどのように呼ばれるかは、テスト駆動開発とは何の関係もないと思います。

そうですね。おっしゃるとおりです。
過程は当事者にしか分かりえないですね。

では、
テストメソッドの実装→メソッドの実装→リファクタリング
の流れがTDDであれば、
メソッドの実装→テストメソッドの実装→リファクタリング
や、
メソッドの実装⇔テストメソッドの実装→リファクタリング
などは、TDDではないということですね。
ただ、TDDではないが、同じような恩恵は受けられる。といった具合でしょうか。

正直、どうでもいい話なんですが、
他人に教えて、その質問の内容がこういった話になった場合、
なんと答えてよいものかと思った次第です。

引用返信 編集キー/

■43216 / inTopicNo.11)

　Re[8]: テストファーストではないTDD

▲▼■

□投稿者/ なぎせゆうき (5回)-(2009/11/02(Mon) 14:20:10)

■No43212 (kyo さん) に返信
> ただ、TDDではないが、同じような恩恵は受けられる。といった具合でしょうか。

「同じような」がどの観測範囲で言っているのかによりますが。
「テストファーストであることによって受けられる恩恵」じゃない部分だけを観測するなら同じですね。

成果物としてプログラムと、自動テストが出来上がりますよ、という部分だけを観測するならば。
あるいは、「まずテストをつくる」ということが何をもたらすかを無視し、単に自動テストが作れればそれでいいよというのであれば。

テストドリブンが、単に「自動テストが残ること」と捉えているなら、認識を誤っていると言わざるを得ません。
そもそもテストドリブンでの自動テストはヒンシツホショウ（漢字だとspamフィルタにひっかかるｗ）のためのテストとは違う種類のテストですしね。

引用返信 編集キー/

■43230 / inTopicNo.12)

　Re[8]: テストファーストではないTDD

▲▼■

□投稿者/ まりも (5回)-(2009/11/02(Mon) 21:36:15)

2009/11/02(Mon) 23:46:33 編集(投稿者)

> では、
> テストメソッドの実装→メソッドの実装→リファクタリング
> の流れがTDDであれば、
> メソッドの実装→テストメソッドの実装→リファクタリング
> や、
> メソッドの実装⇔テストメソッドの実装→リファクタリング
> などは、TDDではないということですね。
> ただ、TDDではないが、同じような恩恵は受けられる。といった具合でしょうか。

自動テストがあることの恩恵、たとえばデグレードが発見しやすいなど、は受けられますね。

が、あたりまえのことですが。
テスト駆動開発の恩恵は受けられません。

たとえば、そのように順番を変えると。
動くコードを書くにはどうすればいいかと、
見やすいコードを書くにはどうすればいいかをわけて、
頭のモードを切り替えて流れ作業的に進めていける、
という恩恵が受けられません。

だから、テスト駆動開発への習熟度にもよりますが、
作業工数は余分にかかることになることもあるでしょう。

またたとえば、そのように順番を変えると。
確実にテストを書いた機能のみを実装することにより、
テストの漏れをなくすことができる、
という恩恵は受けられません。

自動テストの精度は下がるでしょう。

> 正直、どうでもいい話なんですが、
> 他人に教えて、その質問の内容がこういった話になった場合、
> なんと答えてよいものかと思った次第です。

割と重要な話のような気はしますな。

引用返信 編集キー/

■43275 / inTopicNo.13)

　Re[9]: テストファーストではないTDD

▲▼■

□投稿者/ kyo (7回)-(2009/11/04(Wed) 13:03:14)

■No43216 (なぎせゆうきさん) に返信
> ■No43212 (kyo さん) に返信
>>ただ、TDDではないが、同じような恩恵は受けられる。といった具合でしょうか。
>
> 「同じような」がどの観測範囲で言っているのかによりますが。
> 「テストファーストであることによって受けられる恩恵」じゃない部分だけを観測するなら同じですね。
曖昧な表現でした。失礼しました。ここでは単に「自動テスト」という意味だけです。

> 成果物としてプログラムと、自動テストが出来上がりますよ、という部分だけを観測するならば。
> あるいは、「まずテストをつくる」ということが何をもたらすかを無視し、単に自動テストが作れればそれでいいよというのであれば。
>
> テストドリブンが、単に「自動テストが残ること」と捉えているなら、認識を誤っていると言わざるを得ません。
> そもそもテストドリブンでの自動テストはヒンシツホショウ（漢字だとspamフィルタにひっかかるｗ）のためのテストとは違う種類のテストですしね。
なるほど。
そういった観点からTDDを見つめなおしたいと思います。

■No43230 (まりもさん) に返信
> 2009/11/02(Mon) 23:46:33 編集(投稿者)
>
>>では、
>>テストメソッドの実装→メソッドの実装→リファクタリング
>>の流れがTDDであれば、
>>メソッドの実装→テストメソッドの実装→リファクタリング
>>や、
>>メソッドの実装⇔テストメソッドの実装→リファクタリング
>>などは、TDDではないということですね。
>>ただ、TDDではないが、同じような恩恵は受けられる。といった具合でしょうか。
>
> 自動テストがあることの恩恵、たとえばデグレードが発見しやすいなど、は受けられますね。
>
> が、あたりまえのことですが。
> テスト駆動開発の恩恵は受けられません。
>
> たとえば、そのように順番を変えると。
> 動くコードを書くにはどうすればいいかと、
> 見やすいコードを書くにはどうすればいいかをわけて、
> 頭のモードを切り替えて流れ作業的に進めていける、
> という恩恵が受けられません。
>
> だから、テスト駆動開発への習熟度にもよりますが、
> 作業工数は余分にかかることになることもあるでしょう。
>
> またたとえば、そのように順番を変えると。
> 確実にテストを書いた機能のみを実装することにより、
> テストの漏れをなくすことができる、
> という恩恵は受けられません。
>
> 自動テストの精度は下がるでしょう。
自動テストの精度ですか。
私はTDDの経験値は低いものですから、まだ言葉の意味が理解できません。
この言葉の意味を理解するためにも経験を詰まないといけませんね。

>>正直、どうでもいい話なんですが、
>>他人に教えて、その質問の内容がこういった話になった場合、
>>なんと答えてよいものかと思った次第です。
>
> 割と重要な話のような気はしますな。
そういって頂けるとスレを立てた甲斐があります^^。

皆様、コメントありがとうございます。
TDDの良さを理解するには経験を詰むことが前提だということが認識できました。
解決済みとさせて頂きます。
また、宜しくお願い致します。

解決済み

引用返信 編集キー/

■43300 / inTopicNo.14)

　Re[10]: テストファーストではないTDD

▲▼■

□投稿者/ biac (164回)-(2009/11/04(Wed) 22:00:15)

# すっかり出遅れ f(^^;;;

> メソッドを先に書いて、そのテストを書く、
> あるいは、メソッドを作成しながら、そのテストも作成する。
> といったスタイルもTDDと呼ぶのでしょうか？

それは従来の方式ですね。とくに呼び名は無いと思います。
しいて言うなら、「実装と単体テスト」かな。

「アジャイルソフトウェア開発宣言」の会議主催者による、「TDD 三原則」を紹介しておきます。
・失敗するユニットテストを成功させるためにしか、プロダクトコードを書いてはならない。
・失敗させるためにしか、ユニットテストを書いてはならない。コンパイルエラーは失敗に数える。
・ユニットテストを1つだけ成功させる以上に、プロダクトコードを書いてはならない。
( 詳しくはこちらを ⇒ http://www.tdd-net.jp/2009/08/tdd-9534.html )

この 3つのルールから外れたら TDD ではないのです。
私も、「TDD でやってます」と言ってますが、しょっちゅう逸脱しています。 f(^^;;;

TDD は、クラスレベル・メソッドレベルの設計から単体テスト完了までを…、
1. メソッドレベルの外部設計を、自動化されたテストコードという形式で記述し、
2. その外部設計を過不足なく満たすように、製品コードを作成し、
3. その外部設計を変えることなくリファクタリングすることで、製品コードの内部設計を熟成させる
…という 3ステップの手順の繰り返しで進めていこうというプラクティスです。
バグの修正においても、それはテストコードに不足または間違いがあったのが原因だ (外部設計が間違っていたのだ) として、テストコードの追加・修正 → 製品コードの修正 → リファクタリングという同じ手順を踏みます。
もう少し詳しく解説した文書を書いていますので、よろしければどうぞ。 ⇒ http://www.tdd-net.jp/whats-tdd.html

解決済み

引用返信 編集キー/

■43347 / inTopicNo.15)

　Re[11]: テストファーストではないTDD

▲▼■

□投稿者/ kyo (8回)-(2009/11/06(Fri) 12:47:36)

コメントありがとうございます。

■No43300 (biac さん) に返信
> # すっかり出遅れ f(^^;;;
>
>
>>メソッドを先に書いて、そのテストを書く、
>>あるいは、メソッドを作成しながら、そのテストも作成する。
>>といったスタイルもTDDと呼ぶのでしょうか？
>
> それは従来の方式ですね。とくに呼び名は無いと思います。
> しいて言うなら、「実装と単体テスト」かな。
なるほど、これはTDDの手法が発案される以前の方式になるわけですね。

> 「アジャイルソフトウェア開発宣言」の会議主催者による、「TDD 三原則」を紹介しておきます。
> ・失敗するユニットテストを成功させるためにしか、プロダクトコードを書いてはならない。
> ・失敗させるためにしか、ユニットテストを書いてはならない。コンパイルエラーは失敗に数える。
> ・ユニットテストを1つだけ成功させる以上に、プロダクトコードを書いてはならない。
> ( 詳しくはこちらを ⇒ http://www.tdd-net.jp/2009/08/tdd-9534.html )
>
> この 3つのルールから外れたら TDD ではないのです。
> 私も、「TDD でやってます」と言ってますが、しょっちゅう逸脱しています。 f(^^;;;
>
> TDD は、クラスレベル・メソッドレベルの設計から単体テスト完了までを…、
> 1. メソッドレベルの外部設計を、自動化されたテストコードという形式で記述し、
> 2. その外部設計を過不足なく満たすように、製品コードを作成し、
> 3. その外部設計を変えることなくリファクタリングすることで、製品コードの内部設計を熟成させる
> …という 3ステップの手順の繰り返しで進めていこうというプラクティスです。
> バグの修正においても、それはテストコードに不足または間違いがあったのが原因だ (外部設計が間違っていたのだ) として、テストコードの追加・修正 → 製品コードの修正 → リファクタリングという同じ手順を踏みます。
> もう少し詳しく解説した文書を書いていますので、よろしければどうぞ。 ⇒ http://www.tdd-net.jp/whats-tdd.html
非常に厳しいルールですねぇ･･･。
プログラマであれば、思い立ったが吉日といった感じで
思い立った製品コードをガチャガチャと作ってしまいますよね。
それを一旦留めて、メソッドの外部設計をまずする。。厳しいなぁ。

慣れもあるのでしょうが、これは、このルール上でやってみないことには分かりませんね。
まず、ソースエディタ上で、コンパイルエラーが表示されていても、気にしないという壁を越えないと･･･。
（私はきれい好きなので、コンパイルエラーや警告が表示されれば、即座につぶさないと気のすまない性格なもんで）

ありがとうございました。

解決済み

引用返信 編集キー/

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

このトピックに書きこむ

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

- Child Tree -