TDD.NET

[コラム] TDD 道場 @わんくま名古屋勉強会#11

今日 (2010/2/6) 開催された 「わんくま同盟 名古屋勉強会 #11」 の昼休み中に、 TDD 道場をやりました。 まったく初めての試みだったので、 予定通り(?) ぐでぐでになりましたけど、 これからも続けていこうと思います。

TDD 道場とは、 TDD をやってみることに主眼を置いたコーディング道場です。
今回、 説明に使ったスライドはこちらにあります。 ⇒ 勉強会などで使った資料: わんくま勉強会 名古屋#11
お題をどうしようか悩みましたが、 掲示板で助けてもらって、 簡単な FizzBuzz にして 2セッション (VB.NET と Java) やりました。 最初のドライバーだけは決めておいて、 そのあとのメンバーはその場で手を上げてもらったのですが、 .NET チーム / Java チームとも 5分 (だいたい 5分) でドライバー交代していけました。 聴衆からもけっこうツッコミが入ってまして、 最初の試みとしてはまぁそれなりに受けたんじゃないかなと感じました。
2セッションやってみて面白かったのは、 Assert.Are* 派と AssertThat 派、 テストコードのリファクタリング推進派と反対派などなど、 短い時間だったのにいろいろ出てきたことです。 どちらかが絶対に正しいなんていうことは無いわけですけど、 内輪でやってるときには出てこないことなので、 新鮮でした。

以下、 反省点

続きを読む "[コラム] TDD 道場 @わんくま名古屋勉強会#11"

[コラム] RED One, GREEN All

これは、 実行するテストケースの数です。

RED One, GREEN All

すなわち。 テストファーストしているときに、

• テストケースを追加/修正したときは、 そのテストケースひとつだけを実行して RED (失敗) になることを確認すればよい。
• 製品コードを書いたときは、 その部分に関係するテストケースを全て実行して GREEN (成功) を確認しなければならない。

あるテストケースを書いたとき、 そのテストケース以外には何も影響が無いはずですよね。 ですから、 その新しいテストケースだけを実行すればよいわけです。
次に、 その新しいテストケースを通るように製品コードを直しますが、 それによって既存のテストケースが失敗してしまう (つまり、 製品コードにバグを作りこんでしまう) 可能性があります。 したがって、 その製品コードのメソッドを対象としているテストケースは全部流してみる必要があります。
RED を確認するにはテストケース 1つ、 GREEN を確認するには全部、 というわけです。

例として、 C# 2008 Express Edition + NUnit 2.5 の場合を紹介しておきます。

続きを読む "[コラム] RED One, GREEN All"

[コラム] Tech Fielders セミナー 「Agile Day」 に参加しました (2010/01/22)

Microsoft Tech Fielders サイト ・ 開催済みのセミナー (セッション資料) ・ ライトニングトーク資料

マイクロソフトの東京オフィス (新宿) で 2010/1/22 に開催された 「Tech Fielders セミナー 『Agile Day』」 に行ってきました。
参加者数はざっと 60名。 おそらく Windows 系でソフトウェア開発に携わっている人が多いと思います。 そういう中でアジャイル開発に興味を持っていて参加された方々がこれだけいらっしゃったのには、 失礼ながら驚きでありました。 参加者の何人かとお話しさせていただきましたが、 みなさん、 良いソフトウェアを作り出すのは人でありチームであると思っていらっしゃるようで、 心強い想いをいただいて帰途に着くことができました。
※ 私はこのサイトで、 TDD というテクニカルな部分だけを扱っています。 TDD はアジャイル開発に必須と言っていいプラクティスです。 しかし、 良いものを作り出すのは人でありチームであって、 TDD だけをやりさえすれば良いものが出来るなどとはけして思っていません。

今後も開催が予定されているとのこと (まずは 3月と6月) ですので、 今の仕事のやり方に疑問を感じているソフトウェア業界のみなさん、 次は参加してみてはいかがでしょう。 主催のマイクロソフト長沢さんは、 いろいろと変わったことをやってみたいと宣言していましたので、 ますます期待してよさそうです。 また、 企画も募集しています。 ⇒ 長沢智治のライフサイクルブログ 「昨日の Agile Day ありがとうございました！」

続きを読む "[コラム] Tech Fielders セミナー 「Agile Day」 に参加しました (2010/01/22)"

[コラム] [VS2010] 新機能 Generate From Usage (使用法から生成) の使い方 Step by Step

Visual Studio 2010 の新しい機能である "Generate From Usage" ( 使用法から生成 ) について、 そのチュートリアル記事を以前に紹介したことがあります。
そのチュートリアルは、 英語版の CTP に基づいて書かれています。 日本語版の Beta 2 でも基本的には同じですが、 改めて手順を C# で紹介してみます。

VS2008 にはメソッドの生成機能があります。 それは自動生成したコードの方にカーソルが移ってしまうので、 TDD しているときにはテストケースを書いている流れを邪魔されてしまっていました。 VS2010 では、 その点が改善されただけでなく、 クラスの生成機能も追加されています。

興味を持たれたかたは、 Beta 版 (2月には RC 版が公開されるようです) を入手して試してみてはいかがでしょう。 なお、 この機能は Express Edition には搭載されないようですので、 Beta 2 では Ultimate エディション日本語版を使ってください。

続きを読む "[コラム] [VS2010] 新機能 Generate From Usage (使用法から生成) の使い方 Step by Step"

[コラム] どうやって DateTime.Now を含むメソッドをテストする?

TDD Boot Camp でも、 演習の後半に出てきました。 テスト対象のメソッドが、 現在時刻や時間経過に依存しているときは、 どうやったら上手くユニット テストが書けるでしょう?
テストしたい時刻になるまで、 あるいは、 テストしたい時間が経過するまで Sleep() しますか? そんなことをしていたら、 DateTime.Now に依存するメソッドのテストに、 ヘタをすると丸一日掛かってしまうかもしれませんね。

DateTime.Now の値を自由にコントロールできれば、 問題は解決するでしょう。
製品コードの中で、 現在時刻を提供する部分を切り出してしまい、 テストのときはそこをスリ換えてしまうというテクニックがあります。
・ 製品コードに、 現在時刻を提供するクラスを作って、 テストのときはクラスを入れ換える。 (ちょっと大げさだけど、 大きなアプリケーションならけっこう現実的。)
・ 製品クラスの中で、 現在時刻を提供するメソッドかプロパティを切り出して、 テストの時にはそこをすげ替える。
・ 製品クラスの中に、 #if DEBUG で括って、 時刻を調整できるメソッドを仕込んでおく。
・ (…ほかにも方法はあるでしょう。)

以下、 2番目のテクニックを紹介します。

続きを読む "[コラム] どうやって DateTime.Now を含むメソッドをテストする?"

[コラム] TDD Boot Camp、いっぺんに 30組以上がペアプログラミングする壮観!

・ Google Reader で tddbc 関連記事と呟きを見る
・ 和田さんのスライド (当日のお題付き)
・ #tddbc 午前中セッションの録画

12月 19日に開催された "TDD" Boot Camp に参加してきました。 60人を超える参加者がペアプロで TDD する光景は (自分もペアプロしてたのでチラっとしか見てませんが)、 なんとも壮観でした。 何人もの人と知り合うことができて、 とても楽しかったです。 電車の都合で、 懇親会には 15分くらいしか居られなかったのが残念でした。

きっと .NET Framework 組は肩身の狭い思いをするだろうなぁとおもっていたのですが、 チーム分けの最初の時点で 10名、 そのあと 2名加わってくださって 12名になり、 6人一組の C# チームが 2つ出来ました。 小島さんがコーチをしてくださって、 ペアプロで TDD に挑戦です。 開発環境は全員が Visual Studio 2010 beta2 日本語版。 (MS さんのブースにあったデモ機も含めると VS2010 が 15台くらい集まってたことになるんじゃないかな。)

.NET Framework 視点でのイベントレポートは、 MS 長沢さんが詳しく書いてくださってます。 ( ⇒ ITmedia オルタナティブブログ とか、 MSDN のブログ とか、 MSKK のアジャイル開発支援サイト)
ので、 ここではセッションの写真を数枚だけ載せておくだけにします。 携帯電話のカメラなので画質が悪いですけど。

続きを読む "[コラム] TDD Boot Camp、いっぺんに 30組以上がペアプログラミングする壮観!"

[コラム] VS2010b2J (MSTest) で、 Silverlight 3 のロジックを TDD する

[ summary ]

1. Using the unit test feature (MSTest) of VS2010 beta2 (Japanese), it's possible to test the logic included in the Silverlight 3 project.
2. As for the wizards who helps the unit test that VS2010b2J has, some functions don't work normally.
3. The unit test can be executed though warning goes out by the project reference.
4. After the unit test is executed, coverage can be neatly acquired.
5. Logic of Silverlight 3 can be made by using TDD technique. I hope for the support of Visual Studio to be improved.

Visual Studio 搭載のユニット テスト (MSTest) や、 現在の NUnit は、 通常の .NET Framework のランタイム上で動作します。 Silverlight は、 異なるフレームワーク ファミリーのランタイム上で動作しますので、 互換性はありません。 ここで誤解されることがあるのですが (私も誤解していました)、 しかし呼び出しすらできないというわけではありません。 Silverlight  に依存するコードを .NET Framework から呼び出すとエラーになる、 という意味で非互換と言っているようです。

Visual Studio 2010 では、 標準で Silverlight 3 の開発ができます。 そして標準機能のみで、 Silverlight 3 のロジック部分はユニットテストできます。 この記事では、 そのことを実験し、またその手順を説明します。

※ 以下は、 Visual Studio 2010 beta2 日本語版での結果です。 正規版では異なる可能性があります。
※ なお、 Silverlight 4 beta に対しても、 ほぼ同様でした。

続きを読む "[コラム] VS2010b2J (MSTest) で、 Silverlight 3 のロジックを TDD する"

[コラム] Silverlight 2 / 3 でも、ユニットテスト出来る

Silverlight の ver. 2 と 3 では、 通常の .NET Framework のアセンブリと互換性が無いとされています。 Visual Studio 上でテストプロジェクトを作って、 Silverlight のプロジェクトを参照しようとすると怒られてしまいます。 Silverlight Toolkit には単体テストフレームワークが含まれていて、 これは UI まで単体テストできる優れものですが、 いかんせん IE を起動してその上でテストを走らせる仕組みになっているので、 TDD のリズムからはほど遠いものです。

Visual Studio 組み込みのユニットテスト (MSTest) や NUnit から、 サクっと単体テストすることはできないものでしょうか…?

続きを読む "[コラム] Silverlight 2 / 3 でも、ユニットテスト出来る"

[コラム] [Visual Studio] 抽象クラスの private メソッドを単体テストするには

※ 初出: biac の それさえもおそらくは幸せな日々@nifty, 2008年5月2日

Visual Studio では、 プライベートメソッドに対しても、 ユニットテストのスケルトンコードを自動生成してくれます。 プライベートメソッドを持つクラスに対するアクセッサークラスを、 自動的に作ってくれるわけです。 そして、 ユニットテスト側では、 この自動生成されたアクセッサークラスを使って、 テストを書きます。
それを踏まえて…

では、 テスト対象のメソッドが、 抽象クラスに含まれているときはどうすればいいでしょう?

続きを読む "[コラム] [Visual Studio] 抽象クラスの private メソッドを単体テストするには"

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

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

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

…ということです。

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

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