Visual Studio 2005を使ったテスト

単調な単体テストを繰り返し行ってくれるものです。 XP(eXtreme Programming)の重要な要素のひとつです。 テスト機能とは？ 単調な単体テストを繰り返し行ってくれるものです。 XP(eXtreme Programming)の重要な要素のひとつです。 有名なxUnitシリーズなどがあります。

どのエディションで使えるのですか？ Team System VSTO Professional Standard Express C# Team Edition for Database Professional Team Edition for Software Architects Team Edition for Software Developers Team Edition for Software Testers VSTO Professional Standard 残念ながらVSTS, VSTE for SD, VSTE for STしか対応していません。 Express C# Express VB Express C++ Express J# Express Web

全エディションにキャンペーン 全エディションに単体テスト機能をつけようキャンペーンを行ったのですが、今回のバージョンでは3バージョンになってしまいました。

全エディションにキャンペーン 現在はConnectサイトに統合され見た目が変わっています。 おっと3票増えています。(^^

ウォーター フォール プロトタイピング モデルやXP 開発手法として おもな開発手法として、 ウォーターフォール などがあります。

XPをいきなり全社的に 行うのは非常にリスキー リリースは小規模に・複数回（プロトタイピングモデルはウォークスルーの実現だけを行えば破棄してる場合が多い） ペアプログラミング ユーザと物理的に近距離で行う テストコードを書いて常に流す(それをテストのメインにする) XPをいきなり全社的に 行うのは非常にリスキー XPをけなすことが目的ではない。 経営者などがリスキーと考えるからXPを導入できない。事実私も失敗した経験がある。 XPを導入できないからテストフレームワークが使えない・・・・わけではない。

ウォーターフォールとは テストを行っている

テスト項目書つくっていませんか？ この確認を自動化しましょう

Demo 1

TestClass属性の付いているクラスの・・・ [TestClass()] public class 四則演算Test どのような仕掛けで動いているの？ TestClass属性の付いているクラスの・・・ [TestClass()] public class 四則演算Test TestMethod属性の付いているメソッドが対象です。 [TestMethod()] public void 足し算Test() JUnitではTestという名前のメソッドを実行したりしていました。 JUnit4からはアノテーションを利用するようですね。 Nunitも属性ベースのようです。

どのフォルダで動いているの？ ソリューションフォルダのTestResultsというフォルダ配下に、テストのユーザ・マシン・日時\Outというフォルダを作成し、そこで動きます。

テストの実行

テストの実行

テストの実行

テストの実行

テストの実行

テストの実行

実行フォルダの名称などをどのように知るか /// <summary> ///現在のテストの実行についての情報および機能を ///提供するテスト コンテキストを取得または設定します。 ///</summary> public TestContext TestContext このTestContextを利用します。

TestContextってなに？ このようにテストに関する情報等が入っています。 テストの追加情報を出力するためのWriteLineなどもあります。

追加のテスト属性というRegionで囲まれた部分に、テストの準備メソッドなどがあります。 テストを行う順番(Part1) 追加のテスト属性というRegionで囲まれた部分に、テストの準備メソッドなどがあります。 ごらんのようにすべてコメントアウト状態で設定されています。

繰り返し [ClassInitialize()] [TestInitialize()] [TestMethod()] テストを行う順番(Part1) [ClassInitialize()] [TestInitialize()] [TestMethod()] [TestCleanup()] [ClassCleanup()] 繰り返し このようにクラスの最初と、最後。テストの最初と最後にはさまれるメソッドが追加のテスト属性の正体です。

繰り返し 本当はテスト全体の最初と最後もほしい!!! [TestGroupInitialize()] [ClassInitialize()] テストを行う順番(Part1) 本当はテスト全体の最初と最後もほしい!!! [TestGroupInitialize()] [ClassInitialize()] [TestInitialize()] [TestMethod()] [TestCleanup()] [ClassCleanup()] [TestGroupCleanup ()] 繰り返し

public static void MyClassInitialize(TestContext testContext) TestGroupInitialize [ClassInitialize()] public static void MyClassInitialize(TestContext testContext) ClassInitializeはstatic(shared)なメソッドなので、毎回同じstatic(shared)なTestGroupInitializeを呼び static(shared)なフラグで初回しか動かないようにしておけばTestGroupInitializeは実現できます。

[TestGroupInitialize()] [ClassInitialize()] [TestInitialize()] たとえばこんな使い方はどうでしょう [TestGroupInitialize()] DB環境の構築 [ClassInitialize()] クラス全体のテスト環境(マスタ設定など) [TestInitialize()] シナリオに沿った事前準備、トラン系テーブルのクリア、コネクションの確立 [TestMethod()] [TestCleanup()] コネクションの開放 [ClassCleanup()]

テストの種類によってはCSVファイルを用意したりしたい・・・ですよね? テストに必要なものを配置する テストの種類によってはCSVファイルを用意したりしたい・・・ですよね? 　やり方は2つあります。

ソリューションアイテムのtestrunconfigを使うことができます。

配置(1) testrunconfig ここでファイルを指定します。ファイルの追加を行うと、exe,dll,ocxのみのダイアログが開きますが、どんなファイルでも指定することができます。

この設定で配置されるファイルはテスト開始前に1回だけです。 配置(1) testrunconfig この設定で配置されるファイルはテスト開始前に1回だけです。 Testrunconfigによる配置 [ClassInitialize()] [TestInitialize()] [TestMethod()] [TestCleanup()] [ClassCleanup()]

配置されるタイミングなどから、これらの配置は 上書き変更しないもの 環境差などを記述しないもの にとどめましょう。 配置(1) testrunconfig 配置されるタイミングなどから、これらの配置は 上書き変更しないもの 環境差などを記述しないもの にとどめましょう。 とはいえ、

TestMethodのプロパティで設定します。 毎回変更したい配置 　それでは毎回変更したい配置はどうしたらよいのでしょうか？ TestMethodのプロパティで設定します。

配置(2) DeploymentItemAttibute テストビューで配置設定したいテストを選択します

配置(2) DeploymentItemAttibute 配置アイテムという設定があります。 プロパティ

配置(2) DeploymentItemAttibute

配置(2) DeploymentItemAttibute このように指定すると、コピーされるはずです。

配置(2) DeploymentItemAttibute

配置(2) DeploymentItemAttibute サブディレクトリを設定することができます。

配置(2) DeploymentItemAttibute

配置(2) DeploymentItemAttibute この機能の動くタイミング Testrunconfigによる配置 [ClassInitialize()] [TestInitialize()] DeploymentItemによる配置 [TestMethod()] [TestCleanup()] [ClassCleanup()]

配置(2) DeploymentItemAttibute この機能の問題点 ファイルをコピーしたままにする 共通的な設定を含んだものをこの機能で上書きすると、以後の設定が変わったままになる 完全にテストのためだけの資源にしましょう。

配置 まとめ 配置のタイミングと、特性に気をつけて 後始末を必須とするものはコーディングしましょう。 Testrunconfigによる配置 [ClassInitialize()] [TestInitialize()] DeploymentItemによる配置 [TestMethod()] [TestCleanup()] [ClassCleanup()]

そのテストのバリエーションを外部から供給できます。 SQL Server 2005 の AttachDBFileNameも利用可能です データを外部から供給 データを受けて演算するテストがあります そのテストのバリエーションを外部から供給できます。 SQL Server 2005 の AttachDBFileNameも利用可能です 先ほどのDemo1の四則演算で試してみましょう。

Demo 2

DataSource属性を使ったテスト この機能の動くタイミング Testrunconfigによる配置 アタッチ処理 コネクション処理 [ClassInitialize()] [TestInitialize()] DeploymentItemによる配置 [TestMethod()] ←データ件数だけ繰り返し [TestCleanup()] [ClassCleanup()]

AttachDBFileNameの機能の制限 DataSource属性を使ったテスト この機能の問題点 AttachDBFileNameの機能の制限 ファイルの場所がフルパスという問題 デタッチしない(再起動するとデタッチされる) TestResultsフォルダに証拠が残らない 全メンバーのディスク環境をそろえられない

DataSource属性を使ったテスト 回避方法 Testrunconfigで.mdf, .ldfを配置する 本当の初期処理でデタッチする EXEC master.dbo.sp_detach_db @dbname = N'テストデータ', @skipchecks = 'true', @keepfulltextindexfile=N'false' 続いてアタッチする CREATE DATABASE [テストデータ] ON ( FILENAME = N'" + testContext.TestDeploymentDir + @"\テストデータ.mdf' ), ( FILENAME = N'" + testContext.TestDeploymentDir + @"\テストデータ_log.LDF' ) FOR ATTACH

Visual Studioのテストはシンプルにまとまっている Team Foundation Serverとの連携も可能 まとめ Visual Studioのテストはシンプルにまとまっている Team Foundation Serverとの連携も可能 VSTE for Database Professionalという新しい製品でSQLのテストも統合可能 テストファーストという新しい概念を採用しなくても、回帰テストのためにどんどん利用しましょう

Q & A