SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

C#で始めるテスト駆動開発入門

状態を持つクラスをテストファーストする

C#で始めるテスト駆動開発入門(10)

  • X ポスト
  • このエントリーをはてなブックマークに追加

ダウンロード CsTdd10.zip (122.5 KB)

 内部に状態を持つクラスをテストファーストで作るのは、やっかいな仕事です。今回は、そこに取り組んでみましょう。題材としては、前回で取り上げたユニバーサルWindowsアプリのビューモデルを作ります。

  • X ポスト
  • このエントリーをはてなブックマークに追加

対象読者

  • TDDに興味をお持ちの.NET Frameworkの開発者

必要な環境

 サンプルコードを試してみるには、Visual Studio 2013のUpdate 2以降が必要です(無償のExpressで可)。本稿執筆時点では、下記から入手できます。この記事では、Visual Studio Express 2013 with Update 3 for Windowsを使用しています。

開発環境の入手先

 OSにはWindows 8.1が必要です(2014年4月のアップデート、通称「Update 1」が必須)。さらに、Windows Phoneのユニットテストを実行するためには、64bit版Windows 8.1のPro版以上とSLAT対応のPCが必要になります。

 なお、Expressエディションは複数存在していてまぎらわしいのですが、「for Windows」を使います。「for Windows Desktop」は、WPFとWindows Formsの開発用です。

はじめに

TDDはパーツを制作する手法

 最初に少しばかり寄り道を。

 最近、TDDとATDD(受け入れテスト駆動開発)を区別しない意見に出会いました。スペック注1を決めるのはステークホルダーなのだから、TDDはオンサイト顧客を持たない限り成り立たない、というような話でした。ほんとうにそうなのでしょうか?

 TDDとATDDでは、決定すべきスペックの質が違います。レイヤーが違うといってもよいでしょう。

  • ATDD
    受け入れテストとして、アプリのスペックを決める
  • TDD
    ユニットテストとして、パーツ注2のスペックを決める

 例えば、とある画面のスペックを決めているところだとしましょう。立場の異なる2人が、次のように言いました。

  • ステークホルダー
    「☆☆画面で○○ボタンをクリックしたら△△処理をした結果が表示される」
  • 開発者
    「☆☆画面クラスは○○ボタンクリックイベントで△△_Commandを発行する」

 前者は、アプリのスペックを言っています。そこには、△△処理のすべてのテストケースも(暗黙的に)含まれています。受け入れテストは、このレベルのスペックを確認します。

 後者は、パーツ(ここでは画面のクラス)のスペックを言っています。パーツとして見た場合は、ボタンクリックでコマンドが正しく発行されることさえ確認できればOKです。TDDのユニットテストは、このレベルのスペックを確認します。

 この両者、明らかに質が違いますね。そして、アプリのスペックを決定する責任を持つのは、ステークホルダーだということには、異論はないと思います。では、パーツのスペックを決定する責任は誰にあるでしょう? コマンドを発行するのか、メソッドを呼び出すのか、どちらにするかを決めるのは開発者の責任です。

  • アプリのスペックをパーツのスペックにブレークダウンしてから、テストファーストする
  • パーツのスペックを決めるのは、開発者の責任

 なお、一般的にUIそのものをテストファーストするのはコストが見合わないので、TDDで作ってはいけません(勉強や実験のためなら構いませんが)。今回取り上げるのは、UIそのものではなく、テストファーストしやすいビューモデルです。

状態を持つクラス

 パーツのスペックを決めるとき、やっかいなのは内部に状態注3を持っているクラスです。その状態によって挙動が変わるメソッドやプロパティ、あるいは、状態の変化によって発火するイベントなど、どれも単純なメソッドのようにはスペックを決められないでしょう。スペックを決められないと、テストファーストを始められません。

 状態を持つクラスは、第5回『TDDBC大阪の課題をC#でやってみる ~ クラス設計とTDD』(課題は自動販売機)でも扱いましたが、そこではTDDBC大阪の課題を解くことに重点をおいていました。そこで今回は、あらためて状態を持つクラスをテストファーストで作る方法に焦点を当てて考えてみましょう。

注1 スペック

 外部設計(external design)のこと。概要設計と混同しないよう、本稿ではこの言葉を使います。

注2 バーツ

 部品。クラス、メソッド、プロパティ、イベント、デリゲート、演算子など。本稿では、特にユニットテストの対象にできるものを指します。

注3 状態

 ここでは、クラスのインスタンスが保持しているデータ。一般的にはメンバー変数のこと。デザインパターンの一つである「State パターン」にいう状態とは異なります。

【コラム】TDD MANTRA
TDD MANTRA

 

 「TDDって何だっけ?」と感じたときは、スタート地点を振り返ってみましょう。

 次は、TDDの提唱者であるKent Beckの著書『Test-Driven Development: By Example』(訳書『テスト駆動開発入門』)からの引用です(日本語訳は筆者)。

テスト駆動開発において我々は、

  • 自動テストが失敗している場合に限り、 新しいコードを書く
  • 重複を取り除く

これらは 2つのシンプルな規則だ。

この2つの規則は、プログラミングのタスクに対する指令を意味する。

  1. レッド -- 動かない (たぶん最初はコンパイルすらできない) テストを少し書く。
  2. グリーン -- テストを速やかに動くようにする。その過程で必要ならどんな罪をも犯す。
  3. リファクタリング -- テストを動くようにするために作られたにすぎない重複をすべて除去する。

レッド / グリーン / リファクタリング -- TDD の呪文

 この文章をいつでも見られるように、A3ポスター「TDD MANTRA」にしてみました。筆者のOneDriveフォルダーからダウンロードできますので、どうぞご利用ください。

会員登録無料すると、続きをお読みいただけます

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

次のページ
状態を持つクラスをテストファーストする戦略

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
C#で始めるテスト駆動開発入門連載記事一覧

もっと読む

この記事の著者

biac(ばいあっく)

HONDA R&Dで自動車の設計をやっていた機械屋さんが、技術の進化スピードに魅かれてプログラマーに。以来30年ほど、より良いコードをどうやったら作れるか、模索の人生。わんくま同盟の勉強会(名古屋)で、よく喋ってたりする。2014/10~2019/6 Microsoft MVP (Windows Devel...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/8238 2014/11/12 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング