あまりされないTDDの説明

神ノ離忍(かぬりに) @kanu_

「TDDを実践すると実装工程の工数が増え、結果として見積もりの工数が増やさざるを得ないので受託開発では実践しにくい。」

Ryo Asai @ryoasai74

TDDはもちろん、リファクタせず、まともなクラス設計なしでコピペで作った方が工数がみかけ上低いという場合すら。RT @kanu_: 「TDDを実践すると実装工程の工数が増え、結果として見積もりの工数が増やさざるを得ないので受託開発では実践しにくい。」

さかば @sakaba37

テスト駆動開発とチケット駆動開発に共通するのは、小さな単位の積み重ね。これが全体のコストを下げるが、意外と語られる事が少ない。

神ノ離忍(かぬりに) @kanu_

「「TDDの本ってあまり売れないんだそうですよ」から始まる、その理由の考察などのまとめ」をトゥギャりました。 http://togetter.com/li/139936

Hideki Kishida @quicy

また残念な言い方になるけど、TDDは舐められていると思う。「テスト？プログラミング？まーやってるよ。テストは別にJUnitでも手動でもいいし。テストから先に書くなんて面倒なだけで設計良くなるとか無いし、ガーっとコーディングに集中した方がいいもの早くできるのは経験で明らかだって」。

Hideki Kishida @quicy

TDD（テストファースト）は、実際にやってみると経験や直感に反してすごくいい＝やってみないとほとんど良さが分からない、という傾向があるので、そういう意味でも浸透は遅いし、本にも手が伸びないと思う。

さかば @sakaba37

TDDはアジャイルと似ている。アジャイルでは、一度に全体を作成しないで徐々に全体を構成する。常に動作するコードを作成する。イテレーション(繰り返し)の中で改善(リファクタリング)を繰り返す。

さかば @sakaba37

TDDはテストケースを削減する。分岐がｎあるなら、その単純な組合せは２のｎ乗。TDDで分岐の追加毎にテストケース追加ならn+1でサイクロマティック数の簡易版に等しくなりカバレージがほぼ100％。もちろん、2値以外では項目数が増え、パラメータの組み合わせのテストも必要。

さかば @sakaba37

TDDは小さなCI。コードが追加されるたびにビルドされ、過去のテストが実行される。コードの追加やリファクタリングでデグレードが生じていないことが保証されているので、安心して作業できる。

山本康彦＠BluewaterSoft @biac

ただし、品質保証のテストケース数としてそれで良いかは、また別問題かと。 QT @evasys01: RT @sakaba37: …TDDで分岐の追加毎にテストケース追加ならn+1でサイクロマティック数の簡易版に等しくなりカバレージがほぼ100％。…

さかば @sakaba37

はい。「2値以外では項目数が増え、パラメータの組み合わせのテストも必要。」ではだめですか？ RT: @biac: ただし、品質保証のテストケース数としてそれで良いかは、また別問題かと。 QT @evasys01: RT @sakaba37: …TDDで…カバレージがほぼ100％

山本康彦＠BluewaterSoft @biac

実装後に実施する品質保証のためのテストでは、さらに境界値や限界値も見ますよね。 QT @sakaba37:はい。「2値以外では項目数が増え、パラメータの組み合わせのテストも必要。」ではだめですか？ RT: @biac:… QT @evasys01: RT @sakaba37:…

さかば @sakaba37

はい、2値じゃないからですよね。それとも単体以外の一般論ですか？ RT: @biac: 実装後に実施する品質保証のためのテストでは、さらに境界値や限界値も見ますよね。 QT @私:はい。「2値以外では項目数が増え、パラメータの組み合わせのテストも必要。」ではだめですか？

さかば @sakaba37

文字数の限界を感じる今日この頃。５７５は俳人で、Twitterは廃人と言うのは正しいかも、、、

神ノ離忍(かぬりに) @kanu_

RT @katzchang: でも、ユニットテストコードが必要なのであれば、TDDかそれに近い開発スタイルに落ち着いてくるとは思うんですよね。

神ノ離忍(かぬりに) @kanu_

RT @katzchang: 結局、TDDが難しいのではなく、ユニットテストが難しいということだろか。

山本康彦＠BluewaterSoft @biac

.@sakaba37 たとえばFizzBuzzメソッド。TDD三原則に則ってTDDすると、テストケース数は4(=サイクロマティック数)か、三角測量をやって5になる。(続く)

さかば @sakaba37

単純な網羅テストです。アルゴリズム証明的な。ホワイトボックステストですから RT @biac: あらためて質問。何に(あるいは、どういう状況に)比べて、削減されるのでしょう? QT @evasys01: RT @sakaba37: TDDはテストケースを削減する。…

山本康彦＠BluewaterSoft @biac

.@sakaba37 (承前)品質保証のためのテストケース数は、TDDのテストケース数より多くなる。品質保証テストを省略するというのでない限りは、プロジェクトで実施するテストケース数が減るわけではない。

山本康彦＠BluewaterSoft @biac

あらためて質問。何に(あるいは、どういう状況に)比べて、削減されるのでしょう? QT @evasys01: RT @sakaba37: TDDはテストケースを削減する。…

さかば @sakaba37

単純な網羅テストです。アルゴリズム証明的な。ホワイトボックステストですから RT @biac: あらためて質問。何に(あるいは、どういう状況に)比べて、削減されるのでしょう? QT @evasys01: RT @sakaba37: TDDはテストケースを削減する。…

さかば @sakaba37

TDDの良い点の一つは、テストケースが常にテストされている点。類似処理を束ねるのではなく、識別可能な自律的な単位を積み上げて大きなものを作るという、オブジェクト志向とアジャイルに共通するポリシーをかんじる。

山本康彦＠BluewaterSoft @biac

ん～、だいたい理解した(と思う)。「削減する」というより、単に「(単純な網羅テストより)少ない」と QT @sakaba37: 単純な網羅テストです。アルゴリズム証明的な。ホワイトボックステストですから RT @biac: …何に(あるいは、どういう状況に)比べて、削減される…?

さかば @sakaba37

@biac TDD以外だと、ホワイトボックステストと言いながら、ブラックボックステストしながらカバレージツールでチェックするか、デバッガか目視で追うのでしょうね。積み上げではないので、本来は各分岐の組み合わせを網羅した確認が必要かと(されていないでしょうけど)。

さかば @sakaba37

「サン！」と言うのはFizzBuzzがオリジナルで国際的だったんだ。さすが世界のナベアツ！