Visual Studio 2008 でやる テスト駆動開発

Slides:



Advertisements
Similar presentations
C 言語講座第 5 回 構造体. 構造体とは ... 異なる型の値をまとめて新しい型とする 機能がある . つまり , 複数の変数を 1 つのまとまりにできる . 配列と違って同じ型でデータをまとめるのではな く違った型のデータをまとめられる .
Advertisements

わんくま同盟 名古屋勉強会 #3 タダで始めるテストファースト入門 C# Express + NUnit biac 機材協力 : 日本インフォメーション㈱ 2008/7/26.
わんくま同盟 名古屋勉強会 #2 Visual Studio 2008 でやる テスト駆動開発 2008/04/26 biac 機材協力 : 日本インフォメーション㈱ Test Driven Development.
わんくま同盟 名古屋勉強会 #17 biac
テストについて 近畿大学大学院 田中大介 資料:
Struts VS SAStruts ・ STRUTS と SAStruts を比較します。. Struts のメリット1 STRUTS はディファクトスタンダード。 ↓ プログラマがたくさんいる。 ライブラリ、ツールがたくさんある。 ビジネス案件が豊富。 書籍などの情報元が豊富。
Windows Workflow Foundation of .NET Framework 3.0
Visual Studio 2010 の新機能 Coded UI Test
プログラマのレベルアップ.
2008/09/20 TDD 道場 ~ みんな TDD やってみよう! ~.
OJT研修 「テスト実施、テスト設計の技術習得」 日時: 8月22日(月)  場所: 本社5階.
Visual Studio 2008 でやる テスト駆動開発
情報理工学部 情報システム工学科 ラシキアゼミ3年 H 岡田 貴大
プログラミング基礎I(再) 山元進.
Biac /10/25 DI コンテナの本懐 ~ IoC の実装も楽々! biac
Visual Studio 2005を使ったテスト.
RAD Studio 14/09/27 TEffectを使った綺麗なForm
アルゴリズムとデータ構造 2011年6月13日
第6章 2重ループ&配列 2重ループと配列をやります.
2008/09/20 TDD 道場 ~ ぼくと契約して TDD をやってよ! ~.
ノンプログラマのための Selenium de DDT はじめの一歩
MSBuild 色々出来るよ 2011/04/02 お だ.
はじめてのASP.NET 楽しいアプリ制作の会 #1 TWorks.
開発流れ.
リファクタリングのための 変更波及解析を利用した テスト支援ツールの提案
タダで始めるテストファースト入門 C# Express + NUnit
~手続き指向からオブジェクト指向へ[Ⅱ]~
Biac /10/ /10/25 DI コンテナの本懐 ~ IoC の実装も楽々! biac
VBScriptで ユニットテストをやってみる
プロジェクト演習Ⅱ インタラクティブゲーム制作 イントロダクション2
ペアプロ小劇場 劇団ペケぴー 天野勝 永和システムマネジメント 大熊知栄 アジアパシフィックシステム総研
第9章 例外処理,パッケージ 9.1 例外処理 9.2 ガーベッジコレクション.
MVP for VB が語る C# 入門 初音 玲.
MVP for VB が語る C# 入門 初音 玲.
図書館職員のための アプリケーション開発講習会
Windows Azure (CTP) 触ってみた
WPF、MVVMパターン構成.
EclipseでWekaのAPIを呼び出す
プログラミング 4 記憶の割り付け.
Microsoft Visual Studio 2005 Tools for
TDDとメソッドの外部設計 テストファーストの秘訣 2009/08 biac.
i-web RPGX による Web アプリケーション構築
メソッドの外部設計と テストファースト ~ 上手く TDD するために ~
ゲーム開発モデルの基礎.
ミドルウェア”TSUNAGI”を 用いたWEBアプリケーションの構築
ソースコードの特徴量を用いた機械学習による メソッド抽出リファクタリング推薦手法
Windows Azure (CTP) 触ってみた
インタラクティブ・ゲーム制作 プログラミングコース 補足資料
2008/09/20 F# 入門 TDD 道場 ~ みんな TDD やってみよう! ~.
メソッドの外部設計と テストファースト ~ 上手く TDD するために ~
ソフトウェア制作論 平成30年11月21日.
TDD ってどんな感じ? FizzBuzz を作ってみる 2010/01/22 biac 1.
第1章 いよいよプログラミング!! ~文章の表示 printf~
C#プログラミング実習 第3回.
vc-2. Visual Studio C++ のデバッガー (Visual Studio C++ の実用知識を学ぶシリーズ)
アルゴリズムとデータ構造 2012年6月11日
dcNavi:デバッグ支援のための グラフベース推薦システム
System.AddInを利用したアプリケーション拡張 - アドインの開発 -
サブゼミ第7回 実装編① オブジェクト型とキャスト.
nativeの基礎知識 「ポインタ」てなによ!?
WebアプリケーションとTomcat ― これまでの復習とこれからの予習 ―
第5回 プログラミングⅡ 第5回
状況に応じて適切な 例外処理が行なえる アスペクト指向分散環境実験の 支援ツール
プログラム分散化のための アスペクト指向言語
JAVA入門⑥ クラスとインスタンス.
Visual Studio 2013 の起動と プロジェクトの新規作成 (C プログラミング演習,Visual Studio 2019 対応) 金子邦彦.
How To WPF アプリケーション Part4 By 中博俊.
プロジェクト演習Ⅱ インタラクティブゲーム制作
アジャイル開発プロセス 森口朋広.
System.AddInを利用したアプリケーション拡張 - アドインの開発 -
Presentation transcript:

Visual Studio 2008 でやる テスト駆動開発 VS2008 でやる TDD 2008/4/26 Test Driven Development Visual Studio 2008 でやる テスト駆動開発 2008/04/26 biac http://bluewatersoft.cocolog-nifty.com/ 機材協力: 日本インフォメーション㈱

自己紹介 山本 康彦 ( biac ) 名古屋のとある ISV 勤務 もとは機械の設計屋さん いまだにプログラムを書きたがる 50歳 http://bluewatersoft.cocolog-nifty.com/blog/cat8051143/ 名古屋のとある ISV 勤務 現在、 WPF を使った業務アプリケーションの開発プロジェクトで品質保証を担当中 http://www.nicnet.co.jp/page/d_system/d03_12_jisseki.html MSF Agile を部分的に実施中 もとは機械の設計屋さん ものごとの見方・考え方が、きっとズレてる

Test Driven Development テスト駆動開発 ( TDD ) Test Driven Development 1. 単体テストを書く テストは失敗する (RED) 2. 製品コードを書く テストを成功させる (GREEN) 3. リファクタリング (REFACTOR) コードを綺麗に → 1. に戻る RED → GREEN → REFACTOR の リズムに乗って、 さくさく開発

Visual Studio 2008 Express / Std は ? Professional Edition 単体テスト機能はアリ http://msdn2.microsoft.com/ja-jp/library/bb385902.aspx Team System Development Edition さらに、 テストカバレッジ、 コード分析などの機能 http://msdn2.microsoft.com/ja-jp/library/47f7hz7y.aspx Express / Std は ? オープンソースのツールを利用しよう! NUnit, NCover, FxCop …

こんなものを作ってみよう どんなもの? どんな構造? 単体テストできるのは? 誕生日までの日数を答えてくれる。 WPF の画面 画面を抽象化したモデル 返答を作るロジック 単体テストできるのは? ロジック部分のみ UI は、 まだ難しい ・ UI とロジックを分離すべし ・ UI のコード量は減らすべし

画面 / UIModel / Logic の スケルトン まで作っておく DEMO 画面 / UIModel / Logic の スケルトン まで作っておく DEMO 0

最初の一歩 1. [製品] スケルトンを書く 2. 単体テストを生成する 3. [テスト] テストコードを書く メソッドのシグネチャと、 仮の return 文を書く。 TDD の本来の流儀からは、 外れている。 2. 単体テストを生成する 「単体テストウィザード」を使って、 単体テストコードを自動生成する。 3. [テスト] テストコードを書く 4. テストをする ( 失敗するはず ) 5. [製品] テストを通るだけのコードを書く 6. テストをする ( 成功するまで )

最初のテスト と コードカバレッジや コード分析 DEMO 最初のテスト と コードカバレッジや コード分析 DEMO 1

コードの品質保証 テストカバレッジ コード分析 コードメトリックス ※ 以下は、Team System の機能 VS2008 でやる TDD 2008/4/26 コードの品質保証 ※ 以下は、Team System の機能 テストカバレッジ 単体テストのときに、 実行されたコード行をカウント。 ソースを色分けして表示。 ( C0 カバレッジ ) http://msdn2.microsoft.com/ja-jp/library/y8hcsad3.aspx カバーされていないコード == 不要なコード (?) オープンソース: NCover & NCoverExplorer コード分析 Microsoft の基準に沿ったコーディングをしているか、 チェック。 http://msdn2.microsoft.com/ja-jp/library/y8hcsad3.aspx 無視することもできるけど、 後で泣くのは誰? MS の無償ツール: FxCop コードメトリックス コードの複雑さや保守性を測定する。 http://msdn2.microsoft.com/ja-jp/library/bb385910.aspx 点数が悪すぎるところは、 リファクタリング候補。

なぜ単体テストコード? 単体テスト == メソッドレベルの外部設計書 テストに通る == ゴール メソッドのシグネチャと戻り値の定義 (外部設計) は、昔は書いていた ( …らしい)。 厳密に書くのは、自然言語ではムリ。 コードを書けない SE の書いた設計書では、たいがい作れない。 テストに通る == ゴール 自分のリズムに合ったゴールを設定し、さくさく開発。 テストコードを書いた時点で、 わかりにくい仕様書のことは、 とりあえず忘れて OK ! 自動実行できる == リファクタリングできる いつでもすぐに単体テストを実行して、 コードを壊していないことを証明できる。時間さえ許すなら、 気が済むまでコードを改良できる。

TDD は今や常識 開発プロセスの一部 品質向上のコストパフォーマンスが高い たとえば MSF Agile Ver.4 そのほかの Agile プロセスも、 TDD を推奨。 TDD を排斥しているプロセスは無い。 品質向上のコストパフォーマンスが高い 開発プロセス全体では、「実装工程」の工数が少し増えるだけで、コードの品質は飛躍的に向上する。 ( 同じ品質にするなら、結合テスト 2段分 ) 潜在バグ数: 100 70 49 単体テストを書くために、 仕様書をきっちり読む = レビュー効果でバグ 30% 減 単体テストを実施する効果でバグ 30% 減 結合テストで発見されるバグ ≒ 15個 ※ TDD していなければ 30個 ※ 検査 1段で 30% は 1990年代米国の数字 日本では、 もっと良いような感触。

テストメソッドの基本 (1) テストの起承転結 簡単な場合は、 実行と判定を同一行にまとめてもよい。 [TestMethod] public void FooMethodTest() { // テストの準備 (不要なこともある) // → 共通部分は TestInitialize, ClassInitialize へ // テスト実行 --- 製品コードの呼び出し string answer = BarClass.FooMethod(); // 結果判定 Assert.AreEqual(“Hello, TDD!”, answer); // テストの後始末 (不要なこともある) // → 共通部分は TestCleanup, ClassCleanup へ } 簡単な場合は、 実行と判定を同一行にまとめてもよい。

テストメソッドの基本 (2) テストケースごとにテストメソッド 一連のテストケースでひとつのテストメソッド [TestMethod] public void FooMethodTestcase1Test(){ ・・・ } public void FooMethodTestcase2Test(){ ・・・ } 一連のテストケースでひとつのテストメソッド public void FooMethodTest(){ // Testcase1 { ・・・ } // Testcase2 } プロジェクト内でどちらかに統一されていれば良いと思う。

テストメソッドの基本 (3) 例外を期待するテスト: ExpectedException 属性 [TestMethod] [ExpectedException(typeof(System.DivideByZeroException))] public void FooMethodTest(){ int n = BarClass.FooMethod(0); // 0除算例外が期待される } 例外を期待するテスト: try ~ catch try { Assert.Fail(“例外が出て、ここには来ないはずです。"); catch (System.DivideByZeroException){ // ( success! ) テストコードで catch するのは、このパターンだけ。 リソース解放が必要なら finally 句で。

VS便利機能(1) private メソッドのテスト NUnit では、 private メソッドはテストできない public メソッド経由でテストされているはず。 複雑な private メソッドなので、どうしてもそこだけテストしたいときは… public にしてしまったり、 #if DEBUG してみたり。 プライベート アクセッサ 単体テストウィザードで、 private メソッドを指定して単体テストを作ると、 自動的にプライベートアクセッサが生成される。 http://msdn2.microsoft.com/ja-jp/library/ms184807.aspx InternalsVisibleTo 属性 単体テストウィザードで [InternalsVisibleTo 属性を追加する] と、 internal メソッドが見えるようになる。 http://msdn2.microsoft.com/ja-jp/library/bb385840.aspx

DEMO private メソッドの テスト DEMO 2

VS便利機能(2) データドリブン単体テスト 条件を変えて同じテストをする 引数や予想される結果が違うだけで、 同じテストロジックを何度も書くことはめんどくさい。 データドリブン単体テスト DataSource 属性を付けることで、 データソースから 1行読み込むごとにテストメソッドが 1回呼び出されるようになる。 http://msdn2.microsoft.com/ja-jp/library/ms182528.aspx 読み込まれたレコードには、TestContext.DataRow[“{列名}”] でアクセス。 データソースには、データベース、 CSV ファイル、 XML ファイルが利用可能 ODBC データソースが使える == Excel ファイルも OK

DEMO Excel を使った データドリブンテスト DEMO 4

TDD を始めよう TDD は楽しい 参考書 このスライドとサンプルコード コードを書く時間が増える。 ( あいまいな仕様書のことで悩んでいる時間が減る。 テストが書けないなら、 仕様書がおかしい ! ) リファクタリングできる !! 参考書 「Microsoft.NET でのテスト駆動開発」(ジェームス・ニューカーク著) ISBN-13: 978-4891004422 http://www.amazon.co.jp/exec/obidos/ASIN/4891004428/bluewatersoft-22 「リファクタリング ― プログラムの体質改善テクニック」 (マーチン ファウラー著) ISBN-13: 978-4894712287 http://www.amazon.co.jp/exec/obidos/ASIN/4894712288/bluewatersoft-22 Guidelines for Test-Driven Development http://msdn2.microsoft.com/en-us/library/aa730844.aspx このスライドとサンプルコード 次の場所に置いてあります。 http://bluewatersoft.cocolog-nifty.com/blog/cat8051143/

ありがとうございました