TDD.NET

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

TDD = テストファースト + リファクタリング

TDD というコーディング技法について、 詳しくは… ⇒ TDD とは?

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

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

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

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

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

[記事紹介] CodeZine ～ Visual Studio 単体テスト機能大全 第1回: Visual Studio で作る単体テスト、基本のき

この記事はシリーズを予定しているようです。 その名も 「Visual Studio 単体テスト機能大全」 !!
第1回は 「Visual Studio で作る単体テスト、基本のき」 ということで、 既存のコードに対してテストケースを生成する方法、 private メソッドをテストするためにプロキシ クラスを生成させる方法、 internal メソッドをテストする方法、 それと、 テストケース側から製品コードのメソッド スタブを自動生成する方法などについて解説されています。

CodeZine: Visual Studio 単体テスト機能大全 第1回
Visual Studio で作る単体テスト、基本のき
りばてぃ [著] 山田 祥寛 [監修] 2010/02/18

本稿 （および本シリーズ） では主に単体テスト機能にフォーカスしますが、 開発者の利用シーンをキーワードに、 いくつかのシナリオを想定して、 その時々の使い方を取り扱っていきます。

連載ということで、 しかもその初回で基本機能はひととおり説明が終わっていますから、 2回目以降はどんな話になっていくのか、 楽しみです。

[NC] 有償セミナー告知: 5/18 和田卓人の 「TDD の基礎と実践」

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

有償のセミナーなので、 どなたにでもとお勧めするわけにはいかないのですが、 TDD を理解したい・極めたいと思っている人に。

EventForce: テスト駆動開発 (TDD) の基礎と実践
【 技術セミナー 】 主催者: 株式会社日本テクノセンター
開催日時：     05/18(火) 10:30 ～ 17:30
会場：     日本テクノセンター研修室

TDD の伝道師 和田 卓人 氏が講演する!
「 テスト駆動開発 はテスト手法ではなく、設計手法だ!」
実習を通して TDD を理解し、 テスト駆動開発 の威力と効果を現場に活かせ!

■講師の言葉

テスト駆動開発 ( TDD ) は、 名前から想像されるようなテスト技術、 品質保証技術ではありません。 プログラマが自分の書くコードに対して自身を持ち、 プロフェッショナルとして自立するための技術です。

この講座では講演だけでなく実際にハンズオンを通して、 TDD のこころと技を体験し、 TDD を理解していただくことを目的としています。

[ブログ紹介] 深夜のテスト TL

ブログではなくて、 Twitter ですけれど。
2月14日の深夜、 Twitter 上で TDD・テスト・品質保証といった話題が突如盛り上がりました。 私は寝てしまっていて話の流れ (TL: Time Line) に乗れずに、 朝になってから気付いてくやしい思いをしたのでしたが、 fistfvck さんほか数名の方々がまとめてくださいましたので、 メモしておきます。

Togetter: 深夜のテストTL ～ テスト 品質保証厨 tdd

[記事紹介] InfoQ ～ ペア・プログラミングの実際の効果

この記事では、 TDD の上達にも有効なペア プログラミングについて書かれています。 内容は、 表題とはちょっと違って、 効果的なペア プログラミングを実現する 4つのメカニズムについてです。 ( 原題は "How Pair Programming Really Works" )
なお、 この記事の著者は Shane Hastie 氏となっていますが、 以下に引用する部分の原文は、 Royal School of Signals の Stuart Wray 氏によるものです。

InfoQ: ペア・プログラミングの実際の効果
2010年2月7日

開発者としての私個人の経験から、ペア・プログラミングの使用は、一方がプログラムをし、他方が見ているというだけのテクニックではありません。両方のプログラマは、常に話し合いをし、残りのやるべきことを手早くメモし、また、画面上で数々のコードを指摘しながら密接に連携して作業します

上の要約で 「常に話し合い」 と言っていますが、 それが私も一番大切だと思います。 極端に言えば、 「ペアプロとは会話し続けること」 です。

» 続きを読む

[コラム] 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 の場合を紹介しておきます。

» 続きを読む