TDD.NET

[コラム] テストファーストの終了条件 ( どれだけテストを書けばいいのか? )

私はテストファーストの初心者に対しては、 全部のテストケースをユニットテストに書け、 と教えています。 しかし、 TDD 的には全部書かなくてもいいんです。 Uncle Bob の TDD 三原則の 2番目、 「失敗させるためにしか、 ユニットテストを書いてはならない。」 が示しています。 これは言い換えれば、

失敗するテストをもうそれ以上書けなくなったら、 終了

…ということです。

品質保証のためにメソッドのブラックボックステストを作るのとは、 違います。 テストファーストは、 製品コードよりも先にテストケースを書きますから、 ブラックボックステスト的です。 しかし、 テストケースを追加するときには、 既存の製品コードを見るわけですから、 そこはブラックボックステストではなくなります。

続きを読む "[コラム] テストファーストの終了条件 ( どれだけテストを書けばいいのか? )"

[コラム] Web サービスのユニットテスト

TechEd 2009 初日の BoF-02 「Visual Studio 2010 で進化するテスト環境」 に参加してまして、 そこで、 アレっ と思う話が出ました。
Web サービスのユニットテストを数千ケース ( 二千件だったかな ) 書いたはいいけど、 テスト実行にすごく時間が掛かった、 と。

「入り口」 から全部のテストを網羅しようとすれば、 テストケースの数が爆発してしまうのはあたりまえで、 だからこそロジックの中の細かいメソッドごとにテストファーストで作って積み上げていくのですが、 その話はここでは置いといて。

続きを読む "[コラム] Web サービスのユニットテスト"

[NEWS] NUnit 2.5.2 リリース、 次版からは公開場所が変更

8月 10日付けで、 NUnit Version 2.5.2.9222 が公開されました。

ダウンロード ⇒ SourceForge.jp : NUnit .Net unit testing framework プロジェクト トップページ
ダウンロード ⇒ NUnit.org : Download
ダウンロード ⇒ SourceForge.net : NUnit .Net unit testing framework: Files

そのリリースノートによると、 SourceForge.net での配布はこれが最後となり、 次からは http://launchpad.net/nunit-2.5 で公開するとのことです。 ( NUnit.org での配布は継続されると思われます。 )

[ブログ紹介] BDD の導入 - Dan North

BDD ( Behaviour-Driven Development : ふるまい駆動開発 ) の提唱者である Dan North 氏の記事の翻訳です。

Digital Romanticism - digitalsoul のブログ: BDD の導入 - Dan North
2009-08-19

この記事は Dan North 氏の記事 「Introducing BDD」 を氏の許可を得て翻訳した公式版 （"the official translation"） です。 （原文公開日：2006年9月20日）

Dan North 氏は、 ThoughtWorks 社で働いていた 2003年頃から BDD を提唱されています。
※ 現在は ThoughtWorks 社に所属していないかもしれません。 当時所属していたことは、 O'Reilly の紹介ページ(英語) や sys-con.com の Dan North のページ(英語) の自己紹介欄などで判ります。

私自身は、 BDD ( というよりも、 NBehave を使って開発すること ) には懐疑的ですが、 BDD の考え方自体は示唆に富んでおり、 TDD の実践者はこの記事を読んでおくべきだと思います。

続きを読む "[ブログ紹介] BDD の導入 - Dan North"

[コラム] 単体テスト仕様書は不要になるか?

8月 20日に頂いたコメントより。

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

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

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

面白い話題なので、 新しく記事として起こします。

私の考える結論は、 こうです。
・ テスト仕様書やテスト結果のドキュメントが不要になる可能性はあります。
・ 現実的には、 すべてのドキュメントを無くすことはできないでしょう。
・ いずれにしても、 テストの仕様 ( なにをどのようにテストし、 結果はどうなるべきか ) を事前に明確にし、 テストの結果を検証することは必要です。

続きを読む "[コラム] 単体テスト仕様書は不要になるか?"

[ブログ紹介] TDD三原則

正確にはブログではなくて、 個人でやっておられる wiki サイトに掲載された翻訳記事です。

やっとむのサイト: TDD 三原則
Last Change 06/29/09

http://www.butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd の翻訳です。

ぼくはいままで、 テスト駆動開発を3つのシンプルなルールで説明してきた。

1. 失敗するユニットテストを成功させるためにしか、 プロダクトコードを書いてはならない。
2. 失敗させるためにしか、 ユニットテストを書いてはならない。 コンパイルエラーは失敗に数える。
3. ユニットテストを1つだけ成功させる以上に、 プロダクトコードを書いてはならない。

続きを読む "[ブログ紹介] TDD三原則"

[TDD の練習] WinForm を改造したい ～ GUI に埋もれたロジックを分離して、ユニットテストを書く

⇒ TDD の練習シリーズの目次

ネタ元 ⇒ わんくま掲示板 : PictureBoxを左右に往復するループ

質問されたかたはプログラミングの初心者らしく、 どこかから持ってきたサンプルコードを少し改造しようとして苦労しておられました。
※　サンプルコードを動かしてみる → 改造してみる という手法は、 プログラミングに上達するための有効な手段のひとつだと思います。 私も、 いまだによくやります。
掲示板では、 かなり紆余曲折はありましたが、 最後には御自分の納得のいく動きをするコードになったようです。 その途中で 「消えてしまった」 問題を、 ここでは扱ってみます。

・ オリジナルのソース : フォーム上を、 一定速度で画像が左右に動く。
・ やりたいこと : 一回ごとに移動する距離を、 乱数で決めさせたい。
※ 途中で、 「一回ごと」 が 「片道のあいだ中」 に仕様変更され、 「難しい問題」 が消えてしまいました。

今回は、 練習問題というよりも、 GUI からロジックを切り離すリファクタリングを、 ユニットテストのサポート無しで慎重に行う手順を見ていただけたら、 と思います。
回答例のソリューション一式はこちら → WankumaHomework20090810_20090817.zip [69,127バイト]
※ VB 2008 Express + NUnit 2.5 用

続きを読む "[TDD の練習] WinForm を改造したい ～ GUI に埋もれたロジックを分離して、ユニットテストを書く"

[ブログ紹介] 単体テスト用アドイン TestDriven.Net

NUnit 用のテストを NUnitGUI を使わずに直接 Visual Studio 内から実行できるツール、 TestDriven.Net が紹介されています。

MiYABiS note.: VS2008 : 単体テスト用アドイン TestDriven.Net
28 July, 2009

このアドインは NUnit というクラスやメソッドの単体テストを行うためのツールを Visual Studio 上で実行出来るようにするためのアドインです。

TestDriven.Net > Home

このあと、 インストールとテストの実行方法について説明されています。
けっこう便利なアドインなのですが、 基本的に有償です。

[コラム] テストファーストは、 テストを先にやるわけではない

テストファーストでも、 実施順序は 実装 → テスト

テストファーストでは、 テストを先に実施する、 つまり、 従来とは作業順序が入れ替わっている …という誤解があるようですね。
たまたま目に付いた blog 記事をひとつ。

日々吾は: テストファーストでの開発の注意点
2009/07/26

TDDは結局は終わりから始まりに戻るリバースエンジニアリングで

※ ほんとに他意は無いです。 偶然 Google Reader に引っ掛かっただけ。

この一文、 とっさに意味が汲み取れなかったのですが、 どうやら 「テスト → 実装と進めるので、 いままでとは逆の順序なのだ (リバース) 」 という趣旨のようです。 そう気付いて思い返してみると、 そういえば掲示板や他の blog で、 手順が逆になるという話に何回か出会ったような記憶があります。

続きを読む "[コラム] テストファーストは、 テストを先にやるわけではない"

[記事紹介] InfoQ ～ なぜ TDD とペアプログラミングで生産量が増えるのか

この記事は、 TDD などを実施すると品質は上がるだろうけれども生産性は落ちるはずだ、 という誤解についての反論です。

InfoQ: なぜ TDD とペアプログラミングで生産量が増えるのか
2009年6月7日 ( 原文は 2009/2/27 )

「テスト駆動開発」 と 「ペアプログラミング」 は、 アジャイルプラクティスで最も広く知られているものの2つであるが、 まだそれほど多くのアジャイルチームによって実践されてはいない。 たいていその理由として、 TDD やペアプログラミングなどのプラクティスを取り入れるには 「忙しすぎる」 点が挙げられるだろう。 要するに、 これは高いコード品質を得ようと努力することが生産性を低下させることを示唆している。

しかしそうではない、 実際には逆に生産量が増える (生産性は上がる) のであると Mike Hill 氏は反駁しています。

続きを読む "[記事紹介] InfoQ ～ なぜ TDD とペアプログラミングで生産量が増えるのか"