2009/05/29 01:42
BDD (Behavior Driven Development) というものを今更ながら知りました。
言葉だけはたまに見かけてましたが、どんなものか全く知ろうとせず、ずっとどうでもいいやと思っていました。
ところがこれ、TDD を進化させたようなものだったんですね。
「テスト駆動開発」ではどうしても「品質のため」と誤解されがちで、「設計のため」って言っても中々信じてもらえません。でも「ビヘイビア駆動開発」ならきっと大丈夫。
これからは TDD を捨てて BDD へ移行していきたいと思います。
ただ、.NET 界隈だと残念ながら BDD はあまり浸透してない感じですね。具体的にどういう方法で実践していくのが良いか悩みどころです。
[Web 上で見つけた BDD 関連のリンク]
BDD とは何なのかがわかります。
NUnit で BDD を実践する方法の一例が紹介されてます。
MbUnit で BDD を実践する方法の一例が紹介されてます。
.NET 用の BDD フレームワーク「NSpec」
.NET 用の BDD フレームワーク「NSpecify」
.NET 用の BDD フレームワーク「NBehave」
Ruby 用の BDD フレームワーク「RSpec」 (IronRuby を使えば .NET に対応可らしい)
Ruby 用の BDD フレームワーク「Cucumber」 (IronRuby を使えば .NET に対応可らしい)
.NET 用の BDD フレームワーク「Specter」 (Python ライクの .NET 言語である Boo で記述する)
[修正履歴]
2009/05/29
・リンクに Specter を追加。
言葉だけはたまに見かけてましたが、どんなものか全く知ろうとせず、ずっとどうでもいいやと思っていました。
ところがこれ、TDD を進化させたようなものだったんですね。
「テスト駆動開発」ではどうしても「品質のため」と誤解されがちで、「設計のため」って言っても中々信じてもらえません。でも「ビヘイビア駆動開発」ならきっと大丈夫。
これからは TDD を捨てて BDD へ移行していきたいと思います。
ただ、.NET 界隈だと残念ながら BDD はあまり浸透してない感じですね。具体的にどういう方法で実践していくのが良いか悩みどころです。
[Web 上で見つけた BDD 関連のリンク]
BDD とは何なのかがわかります。
NUnit で BDD を実践する方法の一例が紹介されてます。
- NUnitでBDD - サピア・ウォーフの仮説は当てはまらないが。(-.-) - NAgilerの日記
- NUnitでBDD - スペックリスト (^_^) - NAgilerの日記
- NUnitでBDD-継続的インテグレーション (-.-) - NAgilerの日記
- NUnitでBDD-素振り重要 (>_<) - NAgilerの日記
MbUnit で BDD を実践する方法の一例が紹介されてます。
.NET 用の BDD フレームワーク「NSpec」
.NET 用の BDD フレームワーク「NSpecify」
.NET 用の BDD フレームワーク「NBehave」
Ruby 用の BDD フレームワーク「RSpec」 (IronRuby を使えば .NET に対応可らしい)
Ruby 用の BDD フレームワーク「Cucumber」 (IronRuby を使えば .NET に対応可らしい)
.NET 用の BDD フレームワーク「Specter」 (Python ライクの .NET 言語である Boo で記述する)
[修正履歴]
2009/05/29
・リンクに Specter を追加。
スポンサーサイト
2009/04/08 16:40
Trac で MasterTicketsPlugin というプラグインを使うと、チケットのカスタムフィールドに、親チケット (blocking) フィールドと子チケット (blockedby) フィールドを追加できます。これにより、チケットに親子関係を持たせることができます。
僕が気づいた限りでは、次のような機能があるようです。
[Trac Lightning での導入手順]
01. こちらから MasterTicketsPlugin をダウンロードし、解凍します。
02. コマンドプロンプトを開き、解凍したフォルダに含まれる "0.11" フォルダへ移動します。
03. 次のコマンドを実行します。
python setup.py bdist_egg
04. Trac Lightning 用のコマンドプロンプトを開き、"0.11" フォルダの下に作成された "dist" フォルダへ移動します。
05. 次のコマンドを実行します。
easy_install TracMasterTickets-2.1.3-py2.5.egg
06. テキストエディタで "C:\TracLight\python\share\trac\conf\trac.ini" を開きます。
07. components 欄に次の記述を追加します。
mastertickets.* = enabled
08. ticket-custom 欄に次の記述を追加します。
blocking = text
blocking.label = 親チケット
blocking.order = 4
blockedby = text
blockedby.label = 子チケット
blockedby.order = 5
09. 保存します。(エンコーディングは BOM 無しの UTF-8)
10. 依存関係のグラフ表示をしたい場合は、Graphviz をインストールします。
11. [コントロール パネル] - [サービス] にて TracLightning サービスを再起動します。
12. Trac Lightning 用のコマンドプロンプトを開き、各プロジェクトに対し次のコマンドを実行します。
trac-admin プロジェクトフォルダのパス upgrade
[関連]
Trac のプラグインをまとめてみた - かおるんダイアリー
[修正履歴]
2009/04/08 17:52
手順 04, 05 が抜けていたので追加。
僕が気づいた限りでは、次のような機能があるようです。
- チケット表示画面で親チケット・子チケットにリンクが貼られる
- 適切に相互参照されるよう関連チケットの親チケットフィールド・子チケットフィールドを自動更新
- 未解決の子チケットがあるチケットを解決済みにできないようブロック
- チケット表示画面の右上の Depgraph というリンクから依存関係のグラフが見れる (※)
[Trac Lightning での導入手順]
01. こちらから MasterTicketsPlugin をダウンロードし、解凍します。
02. コマンドプロンプトを開き、解凍したフォルダに含まれる "0.11" フォルダへ移動します。
03. 次のコマンドを実行します。
python setup.py bdist_egg
04. Trac Lightning 用のコマンドプロンプトを開き、"0.11" フォルダの下に作成された "dist" フォルダへ移動します。
05. 次のコマンドを実行します。
easy_install TracMasterTickets-2.1.3-py2.5.egg
06. テキストエディタで "C:\TracLight\python\share\trac\conf\trac.ini" を開きます。
07. components 欄に次の記述を追加します。
mastertickets.* = enabled
08. ticket-custom 欄に次の記述を追加します。
blocking = text
blocking.label = 親チケット
blocking.order = 4
blockedby = text
blockedby.label = 子チケット
blockedby.order = 5
09. 保存します。(エンコーディングは BOM 無しの UTF-8)
10. 依存関係のグラフ表示をしたい場合は、Graphviz をインストールします。
11. [コントロール パネル] - [サービス] にて TracLightning サービスを再起動します。
12. Trac Lightning 用のコマンドプロンプトを開き、各プロジェクトに対し次のコマンドを実行します。
trac-admin プロジェクトフォルダのパス upgrade
[関連]
Trac のプラグインをまとめてみた - かおるんダイアリー
[修正履歴]
2009/04/08 17:52
手順 04, 05 が抜けていたので追加。
2009/01/06 00:00
"C:\TracLight" に Trac Lightning をインストールした後、"C:\TracLight\projects" フォルダを "D:\TracLight\projects" に移動する場合。
ちょっと面倒だが、これらの手順を一度踏んでしまえば、以降は特に何も意識する必要がなくなる。
- TracLightning サービスが開始されている場合は停止する。
- "C:\TracLight\projects" フォルダを "D:\TracLight\projects" に移動する。
- "C:\TracLight\CollabNetSVN\httpd\conf\httpd.conf" ファイル内にある全ての "C:\TracLight\projects" を "D:\TracLight\projects" に置換する。
- "C:\TracLight\python\share\trac\conf\trac.ini" 内にある全ての "C:\TracLight\projects" を "D:\TracLight\projects" に置換する。
- 各プロジェクトフォルダ ("D:\TracLight\projects\trac" フォルダ内) の "conf\trac.ini" ファイル内にある全ての "C:\TracLight\projects" を "D:\TracLight\projects" に置換する。
- 各プロジェクトフォルダに対して Trac Lightning のコマンドプロンプトから resync を実行する。 (trac-admin.bat D:\TracLight\projects\trac\xxxxx resync)
- 環境変数に "TL_PROJECT_HOME" を作成し、"D:\TracLight\projects" を設定する。
- TracLightning サービスがインストールされている場合は、[スタート] - [すべてのプログラム] - [サービスのアンインストール] を実行する。
- [スタート] - [すべてのプログラム] - [サービスのインストール] を実行する。
ちょっと面倒だが、これらの手順を一度踏んでしまえば、以降は特に何も意識する必要がなくなる。
2008/08/03 00:15
NDepend というコードメトリクスツールがあります。
コードメトリクスツールとは、コードの品質を測定するツールです。品質を測定することで、コードの改善点を見つけ出し、リファクタリングに繋いでいきます。
例えば、20行を超えるメソッドを (ツールで) 見つけ出し、メソッドの細分化を (プログラマが) 行う、といった具合です。
NDepend は有償ですが、それだけの価値があるツールです。
実際に見てみましょう。
0. ソリューションの用意
新規作成直後のコンソールアプリケーションプロジェクトが 1 つだけ含まれるソリューションを用意してください。今回はこのソリューションを測定します。
1. NDepend プロジェクトの作成
まず、NDepend プロジェクトを作成します。
ツールメニューの [File] - [New Project] をクリックすると、NDepend プロジェクトの名前と保存場所を設定するダイアログが表示されます。
名前と保存場所を入力して [OK] ボタンをクリックすると、NDepend プロジェクトが作成され、画面が次のように変化します。
2. 測定対象アセンブリの設定
次に、測定対象のアセンブリを設定します。
設定の方法はいくつかあるのですが、今回はソリューションファイルで指定します。
[.dd Assemblies of a VisualStudio Solution] ボタンをクリックすると、ファイル選択ダイアログが表示されますので、ソリューションファイルを選択し [OK] ボタンをクリックしてください。
ソリューションファイルで指定すると、ソリューションに含まれている各プロジェクトの出力アセンブリが自動で追加されます。出力アセンブリが見つからないとアセンブリ名の左にエラーマークが表示されます。その場合は、ソリューションのビルドをしてから [Reflesh] ボタンをクリックしてください。
3. 分析の実行
測定対象を設定したら、とりあえず分析を実行します。
ツールメニューの [Analysis] - [Run Analysis on Current Project] をクリックすると分析が開始します。
コンソール画面が表示され、しばらく経つとブラウザでレポートが開かれます。
スクロールするとわかりますが、色々な情報が出力されてます。 (この記事では、これらを細かく解説しません。)
4. CQLのカスタマイズ
NDepend では、測定に CQL という独自のクエリーを使用します。この CQL は SQL に近い文法で、とても簡単に扱うことができます。先ほどの例で挙げた「20行を超えるコードメソッド」を見つけ出すには、
SELECT METHODS WHERE NbLinesOfCode > 20
といった CQL を書きます。 (この記事では、CQL について細かく解説しません。)
では、NDepend に戻ってください。
画面が分析実行前とは違う画面に変化しています。これが NDepend のメイン画面です。
複数のビューがありますが、最も重要なのは画面下の CQL Queries ビューです。ここで CQL の管理を行うわけです。
NDepend では、最初からたくさんの CQL が用意されてますが、今回はこれらの CQL を全て削除してしまいましょう。CQL Queries ペインの左部に列挙されているカテゴリを、[Delete Group] ボタンにて一つずつ削除してください。 ("Constraints extracted from Source Code" は削除できません。)
では、「20行以上のコードで記述されているメソッド」を見つけ出す CQL を追加しましょう。
まず、[Create Group] ボタンにてカテゴリを作成します。今回は名前はそのままでいいです。
次に、[Create Query] ボタンにて CQL を作成します。すると CQL Queries ビューが CQL エディタに切り替わります。
ここで、「20行を超えるメソッド」を見つけ出す CQL を記述するのですが、先ほどの CQL をそのまま記述すると、「20行を超えるメソッド」が見つかっても警告されません。なので、先ほどの CQL の先頭に "WARN IF Count > 0 IN" を加えた CQL を記述してください。これで、1 件でも見つかったら警告されます。
それと、コメントで Name という XML 要素を記述すると、CQL に名前を付けられますので、"Test CQL" と記述しておいてください。
// <Name>Test CQL</Name>
WARN IF Count > 0 IN SELECT METHODS WHERE NbLinesOfCode > 20
記述しましたら、[Save changes] ボタンにて保存します。
5. 測定結果の確認
#Items 欄を見てください。CQL の該当件数が表示されています。CQL の実行は即座に行われ、分析を再実行する必要はありません。
「20行を超えるコードで記述されているメソッド」は現在 0 件のようです。ではここで、ワザと 20 行を超えるコードを用意しましょう。Main メソッドに Console.WriteLine() を 30 行分記述してください。
コードを記述してビルドを行ったら、再び分析を実行してください。すると、レポートが表示されますが、これはひとまず置いておいて、 NDepend にすぐ戻って #Items 欄を見てください (分析結果をロードするかどうかの確認ダイアログが表示されますが OK をクリックしてください。)。
今度は 1 件見つかってます。また、カテゴリと CQL に警告マークが表示されています。
CQL にフォーカスして、左上の CQL Query Result ビューをみてください。ここには、選択した CQL に該当するメソッドが表示されます。
これで、「20行を超えるコードで記述されているメソッド」を検出することができるようになり、しかも該当メソッドが一目でわかるようになったわけです。あとは、検出されるたびに該当メソッドをリファクタリングすることで高い品質を保つことができるというわけです。
先ほど後回しにしたレポートも見てみましょう。[CQL Queries and Constraints] という欄までスクロールしてください。
こちらでも、同様のことが確認できますね。カテゴリと CQL は (警告を表す) 黄色で表示されてます (CQL は警告のみが列挙されます)。また、該当のメソッドも確認できます。
[ 最後に ]
CQL は実に様々な条件を表現できますし、習得は本当に容易です。また、今回はわかりやすくするために削除してしまいましたが、標準でたくさんの CQL が用意されています。今回記述した CQL も、実は標準で用意されてたりします (20 行ではなく 30 行ですが)。
それと、NDepend は Cruise Control.NET などの継続的インテグレーションツールと連携させることができますので、定期的且つ自動的なコード測定も可能です。
NDepend を使えばコードの品質を保ち易くなります。是非、活用してください。
コードメトリクスツールとは、コードの品質を測定するツールです。品質を測定することで、コードの改善点を見つけ出し、リファクタリングに繋いでいきます。
例えば、20行を超えるメソッドを (ツールで) 見つけ出し、メソッドの細分化を (プログラマが) 行う、といった具合です。
NDepend は有償ですが、それだけの価値があるツールです。
実際に見てみましょう。
0. ソリューションの用意
新規作成直後のコンソールアプリケーションプロジェクトが 1 つだけ含まれるソリューションを用意してください。今回はこのソリューションを測定します。
1. NDepend プロジェクトの作成
まず、NDepend プロジェクトを作成します。
ツールメニューの [File] - [New Project] をクリックすると、NDepend プロジェクトの名前と保存場所を設定するダイアログが表示されます。
名前と保存場所を入力して [OK] ボタンをクリックすると、NDepend プロジェクトが作成され、画面が次のように変化します。
2. 測定対象アセンブリの設定
次に、測定対象のアセンブリを設定します。
設定の方法はいくつかあるのですが、今回はソリューションファイルで指定します。
[.dd Assemblies of a VisualStudio Solution] ボタンをクリックすると、ファイル選択ダイアログが表示されますので、ソリューションファイルを選択し [OK] ボタンをクリックしてください。
ソリューションファイルで指定すると、ソリューションに含まれている各プロジェクトの出力アセンブリが自動で追加されます。出力アセンブリが見つからないとアセンブリ名の左にエラーマークが表示されます。その場合は、ソリューションのビルドをしてから [Reflesh] ボタンをクリックしてください。
3. 分析の実行
測定対象を設定したら、とりあえず分析を実行します。
ツールメニューの [Analysis] - [Run Analysis on Current Project] をクリックすると分析が開始します。
コンソール画面が表示され、しばらく経つとブラウザでレポートが開かれます。
スクロールするとわかりますが、色々な情報が出力されてます。 (この記事では、これらを細かく解説しません。)
4. CQLのカスタマイズ
NDepend では、測定に CQL という独自のクエリーを使用します。この CQL は SQL に近い文法で、とても簡単に扱うことができます。先ほどの例で挙げた「20行を超えるコードメソッド」を見つけ出すには、
SELECT METHODS WHERE NbLinesOfCode > 20
といった CQL を書きます。 (この記事では、CQL について細かく解説しません。)
では、NDepend に戻ってください。
画面が分析実行前とは違う画面に変化しています。これが NDepend のメイン画面です。
複数のビューがありますが、最も重要なのは画面下の CQL Queries ビューです。ここで CQL の管理を行うわけです。
NDepend では、最初からたくさんの CQL が用意されてますが、今回はこれらの CQL を全て削除してしまいましょう。CQL Queries ペインの左部に列挙されているカテゴリを、[Delete Group] ボタンにて一つずつ削除してください。 ("Constraints extracted from Source Code" は削除できません。)
では、「20行以上のコードで記述されているメソッド」を見つけ出す CQL を追加しましょう。
まず、[Create Group] ボタンにてカテゴリを作成します。今回は名前はそのままでいいです。
次に、[Create Query] ボタンにて CQL を作成します。すると CQL Queries ビューが CQL エディタに切り替わります。
ここで、「20行を超えるメソッド」を見つけ出す CQL を記述するのですが、先ほどの CQL をそのまま記述すると、「20行を超えるメソッド」が見つかっても警告されません。なので、先ほどの CQL の先頭に "WARN IF Count > 0 IN" を加えた CQL を記述してください。これで、1 件でも見つかったら警告されます。
それと、コメントで Name という XML 要素を記述すると、CQL に名前を付けられますので、"Test CQL" と記述しておいてください。
// <Name>Test CQL</Name>
WARN IF Count > 0 IN SELECT METHODS WHERE NbLinesOfCode > 20
記述しましたら、[Save changes] ボタンにて保存します。
5. 測定結果の確認
#Items 欄を見てください。CQL の該当件数が表示されています。CQL の実行は即座に行われ、分析を再実行する必要はありません。
「20行を超えるコードで記述されているメソッド」は現在 0 件のようです。ではここで、ワザと 20 行を超えるコードを用意しましょう。Main メソッドに Console.WriteLine() を 30 行分記述してください。
コードを記述してビルドを行ったら、再び分析を実行してください。すると、レポートが表示されますが、これはひとまず置いておいて、 NDepend にすぐ戻って #Items 欄を見てください (分析結果をロードするかどうかの確認ダイアログが表示されますが OK をクリックしてください。)。
今度は 1 件見つかってます。また、カテゴリと CQL に警告マークが表示されています。
CQL にフォーカスして、左上の CQL Query Result ビューをみてください。ここには、選択した CQL に該当するメソッドが表示されます。
これで、「20行を超えるコードで記述されているメソッド」を検出することができるようになり、しかも該当メソッドが一目でわかるようになったわけです。あとは、検出されるたびに該当メソッドをリファクタリングすることで高い品質を保つことができるというわけです。
先ほど後回しにしたレポートも見てみましょう。[CQL Queries and Constraints] という欄までスクロールしてください。
こちらでも、同様のことが確認できますね。カテゴリと CQL は (警告を表す) 黄色で表示されてます (CQL は警告のみが列挙されます)。また、該当のメソッドも確認できます。
[ 最後に ]
CQL は実に様々な条件を表現できますし、習得は本当に容易です。また、今回はわかりやすくするために削除してしまいましたが、標準でたくさんの CQL が用意されています。今回記述した CQL も、実は標準で用意されてたりします (20 行ではなく 30 行ですが)。
それと、NDepend は Cruise Control.NET などの継続的インテグレーションツールと連携させることができますので、定期的且つ自動的なコード測定も可能です。
NDepend を使えばコードの品質を保ち易くなります。是非、活用してください。
2008/06/12 00:03
諸君、私はテスト駆動開発が好きだ
諸君、私はテスト駆動開発が好きだ
諸君、私はテスト駆動開発が大好きだ
レッドが好きだ
グリーンが好きだ
リファクタリングが好きだ
アジャイルプロジェクトで
ペアプログラミングで
この地上に存在するありとあらゆるテスト駆動開発が大好きだ
ユニットテストがもたらす安心感が好きだ
リファクタリングを始める時など心がおどる
シンプルなコードが好きだ
リファクタリングによって洗練されていく様など胸がすくような気持ちだった
設計が常に成長していく様が好きだ
責任が適切に分担されていく様子など感動すらおぼえる
グリーンになると思い込んでいたのにレッドだった時などもうたまらない
いつでも一瞬で全てのコードがテストできるのは最高だ
気づきをもたらしてくれるレッドが好きだ
レッドを省略して実装を進めていく人はとてもとても悲しいものだ
リファクタリングの徹底が好きだ
余計な事だと馬鹿にされるのは屈辱の極みだ
諸君 私はテスト駆動開発を 楽園の守護者の様なテスト駆動開発を望んでいる
諸君 私に付き従うテスト駆動開発好きの諸君 君たちは一体何を望んでいる？
更なるテスト駆動開発を望むか
糞の様なテスト駆動開発を望むか？
バグの手から私たちを守ってくれる女神のようなテスト駆動開発を望むか？
「テスト駆動開発！！」 「テスト駆動開発！！」 「テスト駆動開発！！」
よろしい ならばテスト駆動開発だ
だが、古い開発プロセスが染みついた場所で変化を拒む連中に耐え続けて来た我々には
ただのテスト駆動開発ではもはや足りない！！
大テスト駆動開発を！！ 一心不乱の大テスト駆動開発を！！
我々はわずかに小数
ウォーターフォール派に比べれば物の数ではない
だが諸君は一騎当千の偉大な習慣を身に付けし者だと私は信じている
ならば我らは諸君と私で総兵力100万と1人の救世主の集団となる
我らを忘却の彼方へと追いやり、悪しき習慣にしがみついている奴等を叩きのめそう
髪の毛をつかんで引きずり下ろし 眼(まなこ)をあけて思い出させよう
連中に向上心を思い出させてやる
連中に勇気を思い出させてやる
テスト駆動開発には奴らの哲学では思いもよらない楽しさがある事を思い出させてやる
1000人の偉大な習慣を身に付けし者の集団で 世界を偉大な習慣で埋め尽くしてやる
目標 プログラムの楽しさを忘れてしまった者達
Be Agile 作戦 状況を開始せよ
逝くぞ 諸君
C# でも PowerShell でもなく TDD で挑戦 (?) してみました。
(一部過激な表現が含まれていますが、ネタですのでご勘弁を)
ネタ元 : 諸君、私は ECMAScript が好きだ - IT戦記
ジェネレータ : 「諸君、私はほにゃららが好きだ」ジェネレータ
2007/08/28 17:26
NAgilerの日記 - Agile Principles, Patterns, and Practices in C# (^o^)
なんと、書籍「アジャイルソフトウェア開発の奥義」の C# 版だそうです
ほ、ほしぃ・・・。でも洋書読めない ；－；
邦訳版が出てくれることを祈ります ( できれば、アジャイルソフトウェア開発の奥義と同じ人の翻訳で ＾＾ )
# よく見たらけっこう前 ( 2006年8月 ) に出てたんですね、知らなかった ＾＾；
2007/07/21 21:55
テスト駆動とかXPとかアジャイルとか、興味はあるけどまだ実践したことはありません。
顧客常駐なんて、ウチじゃさすがに無理だと思いますが、テスト駆動は取り入れようと思えば取り入れられると睨んでます。
.NET開発ならNUnitとかNMockとかTestDriven.NETとかを使用する、ということくらいは知ってますが、インストールしたっきり全然使ってなかったりします＾＾；
で、次の案件ではテスト駆動開発を取り入れようと密かに企んでいたのですが、craftsmanさんの
オブジェクト思考: テスト駆動開発やユニットテストを定着させるには という記事を読んで、僕はテスト駆動開発についてのしっかりとした知識を持っておらず、とても危険だったということを思い知らされました。
だって、「構成管理システムによってテスト実行を自動化させる」 なんて事、全く知らなかったんです。普通に手動でNUnitを実行させればいいとばかり思ってました。
こりゃ、取り入れる前にしっかり勉強しとかないと。。。せっかく新しいことをやっても、知識不足のせいで失敗に終わったら台無しですからね。
顧客常駐なんて、ウチじゃさすがに無理だと思いますが、テスト駆動は取り入れようと思えば取り入れられると睨んでます。
.NET開発ならNUnitとかNMockとかTestDriven.NETとかを使用する、ということくらいは知ってますが、インストールしたっきり全然使ってなかったりします＾＾；
で、次の案件ではテスト駆動開発を取り入れようと密かに企んでいたのですが、craftsmanさんの
オブジェクト思考: テスト駆動開発やユニットテストを定着させるには という記事を読んで、僕はテスト駆動開発についてのしっかりとした知識を持っておらず、とても危険だったということを思い知らされました。
だって、「構成管理システムによってテスト実行を自動化させる」 なんて事、全く知らなかったんです。普通に手動でNUnitを実行させればいいとばかり思ってました。
こりゃ、取り入れる前にしっかり勉強しとかないと。。。せっかく新しいことをやっても、知識不足のせいで失敗に終わったら台無しですからね。
Calendar
