TDD.NET

CodeZine に記事を書かせていただきました。

CodeZine: C#で始めるテスト駆動開発入門（4） TDDで仕様変更とデバッグをする方法
2012/5/29

CodeZine: C#で始めるテスト駆動開発入門（5） TDDBC大阪の課題をC#でやってみる ～ クラス設計とTDD
2012/6/29

この2回では、 デバッグや仕様変更のときのやり方、 クラス設計を進めながらテストファーストするときの考え方と、 わりと実践に即した話をしました。
次からは、 .NET Framework に特化して、 日付やデータベースの扱い方を説明していく予定です。

・ はてなブックマーク - TDDで仕様変更とデバッグをする方法（1/5）：CodeZine

・ はてなブックマーク - TDDBC大阪の課題をC#でやってみる ～ クラス設計とTDD（1/7）：CodeZine

CodeZine に記事を書かせていただきました。

CodeZine: C#で始めるテスト駆動開発入門（2） Visual StudioのMSTestでTDDを行う方法
2012/2/10

CodeZine: C#で始めるテスト駆動開発入門（3） NUnitの全貌 ～ 基本から、最新バージョンの新機能まで
2012/4/13

C# の主なテスティング フレームワークである MSTest と NUnit の使い方を、 連載 2回を使って紹介しました。 次回からは、 デバッグのやり方など、 TDD の話に戻る予定でいます。

・ はてなブックマーク - Visual StudioのMSTestでTDDを行う方法（1/6）：CodeZine

・ はてなブックマーク - NUnitの全貌 ～ 基本から、最新バージョンの新機能まで（1/8）：CodeZine

Microsoft の月刊誌 「MSDN マガジン」 (昔は紙の雑誌でした。 今は Web で読めます。) に掲載された記事から、 TDD に関連するものをいくつか挙げておきます。

2011年 6月号: Visual Studio と TFS でアジャイル C++ 開発とテストを行う
John Socha-Leialoha

今回の記事では、マイクロソフト所属のチームがアプリケーション開発に使用している数多くの手法を紹介します。

2010年 12月号: BDD 入門 ～ SpecFlow と WatiN によるビヘイビア駆動開発
Brandon Satrom

今回の記事では、BDD の概要を簡単に紹介し、単体レベルの実装につながる機能レベルのテストによって、BDD サイクルに従来のテスト駆動開発 (TDD) サイクルがどのように組み込まれるかを説明します。

2009年 6月号: テスト駆動型設計 ～ モックとテストを使用して役割に基づいたオブジェクトを設計する
Isaiah Perumalla

この記事では、次の内容について説明します。

• 実装ではなく対話をテストする
• 役割を見極め、相互のやり取りを抽象化する
• 相互のやり取りを抽象化する
• コードをリファクタリングして意図を明確化する

2009年 2月号: IronRuby と RSpec の概要 (第1部)
Ben Hall

この記事では、次の内容について説明します。

• Ruby とアヒル型定義
• Ruby と Microsoft .NET Framework
• IronRuby と RSpec を使用する

CodeZine に記事を書かせていただきました。

CodeZine: C#で始めるテスト駆動開発 ～ TDDBC横浜の課題をやってみよう
2011/12/12

本サイトで書いていること^*1と同様の内容ですが、 細かい手順の説明などは省いて読みやすくしました。 ご感想や、 ツッコミ・要望などを、 ここのコメント欄か掲示板にいただけると幸いです。

※ *1: 「VB2010 Express + NUnit 2.5 で、 初めてのTDD Step by Step」 や 「C# 2008 Express + NUnit 2.5 で、 初めてのテストファースト Step by Step」 など。

・ はてなブックマーク - C#で始めるテスト駆動開発（1/7）：CodeZine

テストケースを書いているときに、 これから作る (まだ存在しない) クラスやメソッドの名前を入力すると、 Visual Studio のインテリセンスが「邪魔」をしてくれて、 イラつくこと甚だしいのですが…。

長沢智治のライフサイクルブログ: Visual Studio 2010 言語別ショートカット一覧とテスト駆動開発用の便利な使い方
31 Oct 2011

普段は、非常に便利な IntelliSence も、テスト駆動開発 (TDD) では、存在しないクラスやメソッドを呼び出すテストコードを最初に記述するため、IntelliSence の強力なコード補完能力がものすごく邪魔になりますw

そんな時は、「Ctrl + Alt + Space」 で、モードを切り替えれば、存在しないクラスやメソッドを簡単に記述できますし、候補にも表示されるようになります:

※通常、存在しないクラスなどを記述し Space キーを押すと一番近い存在するクラスを補完してくれますが、モード切替で、それを無効にすると、上記のように、自然な流れで記述でき、かつ、new とかすれば、候補として最適なものが選択もできてしまいます。

画面上は、 new の右下、 候補リストの上に、テキストボックスのような四角が表示されているところが違います。 これは、 IntelliSense の "候補提示モード" (suggestion mode) と呼ばれる状態で、 以前からの動作は "入力候補モード" (completion mode) と呼ばれます。
詳しくは MSDN の解説をどうぞ。 ⇒ http://msdn.microsoft.com/ja-jp/library/exbffbc2.aspx

1年ほど前に紹介した記事が、 VS2010 に対応した改訂版になっています。

CodeZine: Visual Studio 単体テスト機能大全 第1回
Visual Studio で作る単体テスト、基本のき (VS2010向け改訂版)
りばてぃ [著] 山田 祥寛 [監修] 2011/04/04

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

以前の記事は VS2008 でしたが、 環境を 2010 に変えて書き直されています。
本サイトでは無償の NUnit に偏って紹介していますので、 Visual Studio (Pro. 版以上) に付属の単体テスト機能 (MSTest) を使ってみようという方は、 この記事をお読みいただくとよいかと思います。

ちなみに私が MSTest を使うときは、 製品コード側にダミーでいいのでメソッドをひとつ書いてから、 テストプロジェクトを自動生成させています。 やはり、 楽なので。 プロジェクト作成後は、 テストコード先行の TDD になります。 プライベートメソッドをテストするためのプロキシクラス自動生成機能は、 めったに使いません。

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

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

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

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

※ 2011/4/4付けで、 VS2010 に対応した改訂版が出されています。

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

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

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

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

この記事では、 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 法人 國際松濤館空手道連盟の道場、 またそこで教えている流儀や開催している大会のことらしい)

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 を操作するコードもテストできるわけです。