TDD.NET

[お知らせ] ようこそ、 TDD.NET へ

掲示板を設置しました ⇒ TDD.NET 掲示板

このサイトでは、 .NET Framework での開発、 その中でも主に C# / VB.NET を使って TDD するときに役立つ日本語の情報を集めていきます。 VC++ については門外漢なので、 ほとんど載らないと思います。

このサイトは、 独立した記事と、 blog と、 掲示板から構成されています。 左サイドバーの [ コンテンツ ] からご利用くださると便利かと思います。

ご意見・ご要望等がございましたら、 掲示板に書いていただくなり、 この記事にコメントを付けるなりトラックバック打つなり、 私に直メールするなりしていただけると嬉しいです。

※ トラックバックは、 フィッシングサイトや営利目的のものはお断りします。 そのために、 承認制としておりますので、 トラックバックが反映されるまでしばらく掛かります。

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

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

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

以下、 反省点

» 続きを読む

[お知らせ] 記事 「TDD とは?」 に 「TDD 三原則」 を追記

TDD の概要を解説した記事 「TDD とは?」 に、 「TDD 三原則」 の章を追加しました。

⇒ TDD とは?: 3. TDD 三原則

[NC] イベント告知 - TDD Boot Camp 北陸 (3/13-14, 石川県白山市)

※ NC : Non-Category です。 カテゴリー別の記事には含まれません。 バックナンバーには残ります。

TDD Boot Camp 北陸

TDD の原則は 「テストを書いてからコードを書く」。 ただ、 実際にはこの原則の裏には様々な技法や知識が隠されており、 実際の開発現場で使いこなすには 「見えない壁」 があることも事実です。 この現状を解決する機会が切望されています。

そこで TDD Boot Camp 北陸では、

• 講師による講演
• ペアプログラミングによる TDD 体験とチームでのコードレビュー

を行い、 TDD に対する理解を深めることを目的としています。

つまり…
2009年12月に行われたイベント 「TDD Boot Camp ～ TDD をつかめ ～」の再来です！

» 続きを読む

[記事紹介] Coding Dojo: InfoQ ～ TDDを根づかせる:導入の問題と解決策

この記事では、 TDD を根付かせるための方策をいくつか提案しています。 そのひとつに、 「乱取り形式」 (Randori Format) による 「コーディング道場」 (Coding Dojo) があります。 これは楽しそうです。

InfoQ: TDDを根づかせる: 導入の問題と解決策
作者 Mark Levison, 翻訳者 角谷 信太郎
2009年4月28日

コーディング道場 (での「乱取り稽古」) は、 小規模なグループ (最大15人まで) で、 TDD を使って課題を解く (Danilo  Sato のアイデアを取り入れたもの)。 進め方はこうだ。:

• プロジェクタに接続された 1台の PC でコーディングする。
• ペアでコーディングする。
• 5 ～ 10分間隔でペアの片方を交代する (筆者の経験では 7分単位での交代がうまくいった)。
• コーディングを担当しているときは、 自分が何をしているのかを説明しながらキーボードをタイプする。 こうすることで聴衆も、 何が起きているのかを理解できる。
• 聴衆は、 テストがきちんと通っている場合にだけ、 設計について意見を述べてもよい。 テストが通っていない状態では、 設計については質問しかできない。
• 聴衆が現在おこなわれている作業について混乱してきたら、 コーディングしている人は手を止めて、 自分がいまやっていることを説明しなければならない。

余談ですが、 海の向こうのプログラミング界ではなぜか長らく空手が流行っています。 TDD ネタの blog でも、 Kihon, Kata, Kumite といった単語が飛び交います。 Shotokan (松濤館) にいたっては何のことだか分かりませんでした。 (NPO 法人 國際松濤館空手道連盟の道場、 またそこで教えている流儀や開催している大会のことらしい)

[コラム] RED One, GREEN All

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

RED One, GREEN All

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

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

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

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

» 続きを読む

[コラム] 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 セミナーの資料を掲載しました

2010/1/22に Microsoft 主催で開かれた 「Tech Fielders セミナー Agile Day」 にて、 LT に登壇させていただきました。 そのときのスライドを公開します。 (1/28 追記: Tech Fielders のサイトでも公開されました。 ⇒ セッション、 LT)

「TDD ってどんな感じ? ～ FizzBuzz を作ってみる」
FizzBuzzByTDD20100122.ppt (PowerPoint; 576.0KB)
FizzBuzzByTDD20100122.pdf (PDF; 683.8KB)

かなり無謀な枚数のスライドでして、 残念ながらというか案の定というか、 2ページ残してタイムアップとなってしまいました。 これまで何回か LT をやってきましたが、 初めての 「敗北」 です。
なお、 資料の末尾にはさらに、 質問があったときのための仕込みとして、 バグが出たときの TDD 的な対応についても書いてあります。 (こちらは、 時間内に喋るつもりは最初から無かった部分です。)

[記事紹介] JavaScript の単体テストツール、 JsUnit と QUnit

ASP.NET AJAX のおかげで、 .NET Framework を使った開発で JavaScript をゴリゴリ書くような場面は、 めっきり減ったと感じています。 それでも、 イザということがあるかもしれませんので、 単体テストをサポートしてくれるツールの存在は知っておいたほうが良いかと思います。 そこで、 少し調べてみたところ、 このごろ有力なものとして JsUnit と QUnit の 2つがあるようです。

InfoQ: JsUnit と JSMock を使った JavaScript のテスト駆動開発
2009年4月9日

マイコミジャーナル: 【レポート】 jQuery テストスイート「QUnit」がスタンドアロン化! 使い方を早速チェック
2009/10/14

どちらも、 HTML ファイルの中にテストを記述し、 テストの実行は Web ブラウザーからという形態をとります。 そのため、 テスト用の HTML にダミーのボタンなどを配置すれば、 DOM を操作するコードもテストできるわけです。

» 続きを読む

[記事紹介] ZDNet Japan ～ ソフトウェアの新たな開発手法、「アジャイル開発」って?

TDD からは離れますが、アジャイルソフトウェア開発について解説した記事を紹介します。著者の一橋氏は、複数のアジャイル開発プロジェクトを成功させた経験を持っています。TDD はアジャイル開発のプラクティスのひとつと位置づけられることが多いので、 参考になると思います。

ZDNet Japan: 今さら人に聞けない IT トピック - ソフトウェアの新たな開発手法、「アジャイル開発」って?
2006年9月29日
一橋範哉 (ウルシステムズ)

ソフトウェア開発の新たな手法としてアジャイル開発が紹介されてから数年が経過し、実プロジェクトへの適用事例を目にすることが多くなってきました。アジャイル (agile) とは、「俊敏な」「機敏な」という意味ですが、「ペアプログラミング」「テストファースト」のようなアジャイル開発手法の一部のプラクティスがそのすべてであるかのように言われることがあります。ここでは改めてアジャイル開発の基本的な考え方を整理していきたいと思います。

» 続きを読む