bols-blue · October 7, 2012 02:55 · Oct 4, 2012 · Oct 4, 2012 · Oct 4, 2012 · Oct 4, 2012
diff --git a/Database_testing.md b/Database_testing.md
@@ -67,4 +67,5 @@ OracleやDB2等商用のRDBは非常に多くの設定自動化機能やチュ
 * [レガシーコード改善ガイド](http://www.amazon.co.jp/dp/4798116831/)
 * [データベース・リファクタリング](http://www.amazon.co.jp/dp/4894715007)
     * [Liquibase](http://www.liquibase.org/)
-* [xUnit Test Patterns: Refactoring Test Code](http://www.amazon.co.jp/dp/0131495054)
+* [実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる](http://www.amazon.co.jp/dp/4798124583)
+* [xUnit Test Patterns: Refactoring Test Code](http://www.amazon.co.jp/dp/0131495054)
diff --git a/Database_testing.md b/Database_testing.md
@@ -67,3 +67,4 @@ OracleやDB2等商用のRDBは非常に多くの設定自動化機能やチュ
 * [レガシーコード改善ガイド](http://www.amazon.co.jp/dp/4798116831/)
 * [データベース・リファクタリング](http://www.amazon.co.jp/dp/4894715007)
     * [Liquibase](http://www.liquibase.org/)
+* [xUnit Test Patterns: Refactoring Test Code](http://www.amazon.co.jp/dp/0131495054)
diff --git a/Database_testing.md b/Database_testing.md
@@ -56,7 +56,7 @@ OpenOfficeや新し目のExcelはxmlとしてファイルを保存するオプ
 特定のクエリに非常に大きなコストがかかっている事が発見された場合、緊急性の高い問題として管理される事になります。  
 本番環境とテスト環境における設定に大きなずれがあると、問題を再現するだけでも大きな手間がかかる事になります。  
 
-OracleやDB2等商用のRDBは非常に多くの設定自動化機能やチューニングの自動化機能を持っていますし、
+OracleやDB2等商用のRDBは非常に多くの設定自動化機能やチューニングの自動化機能を持っていますし、  
 投入可能なハードウェアリソースに制限がある為に、  
 厳密に本番環境とテスト環境の設定を同じにする事は出来無い事が多いのですが、  
 設定を出来る限り近付ける作業を定常作業として開発プロセスに組み込んで下さい。  

diff --git a/Database_testing.md b/Database_testing.md
@@ -0,0 +1,69 @@
+# データベースを使った自動テストについて
+
+データベースを使った機能テストや単体テストについて要点をまとめておきます。   
+
+筆者の経験を強く反映していますので比較的定性的な内容となります事を予めご了承下さい。
+
+## テストデータを保守する
+
+テストの実行前に投入するテストデータは、凡そcsvファイルやxmlファイル、エクセルファイル等で管理する事になります。  
+仕様の変更に伴いテーブルの定義を変更する事で、それらのファイルの内容とデータベースの間に不整合が発生します。  
+テーブル定義の変更とテストデータの保守は常にまとめて作業するべきです。  
+これは同じ作業者がやるべきという事ではありませんが、ほぼ同時期に行われるべきです。  
+
+RDBを使っている場合、ExcelやAccessといったデータベースにODBC接続し易いツールを使うとデータを作り込み易いのですが、  
+テストデータを長期間に渡って保守する事を考えると、  
+テストデータもソースコードと同様にGitやSVN等のバージョン管理システムに取り込む事で大きく利便性が向上しますので、csvやxml等のテキストデータを使って保存する事が望ましいです。  
+OpenOfficeや新し目のExcelはxmlとしてファイルを保存するオプションがありますのでできる限りそちらを使って下さい。
+
+テストデータを保守する作業を開発プロセスの中に盛り込む事が出来ない場合、  
+データベースを使ったテストは有効性及びその価値を大きく低減する事になります。
+
+## テストからデータベースを守る
+
+データベースを使ったテストは、理由は様々あれど仕様上整合性の取れないデータをデータベース内に残してしまったり、不用意にデータを削除してしまったりしがちです。  
+特にチームメンバーがデータベースを使ったテストに慣れていないうちは、その様な事がよく起こります。
+
+理想的な対応策から順に列挙します。
+
+* テスト用のデータベースをテーブル定義のみにして、テスト開始時に投入したデータを、テスト終了時には全て削除する。
+* テスト用のデータベースを分離しておき、いつ壊れても良いようにする。
+* テスト用のデータベースのデータをバックアップから復元する方法をチームメンバー内で共有し、失敗に気づいたら即復元出来る様にしておく。
+
+プロジェクトの開始時からデータベースを使ったテストをしていない限り、2番目の対応もしくは3番めの対応となるでしょう。
+
+
+## 最初は複雑なトランザクションをテストしない
+
+データベースを使ったテストは複雑になりがちですので、チームメンバーが慣れるまでは1つのテーブルだけを使う様なテストを記述するべきです。  
+
+
+## データベースを使うテストを分離しておく
+
+1プロセス内で完結する単体テストに比べて、  
+データベースというプロセスと積極的にTCP通信するテストはどうしても遅くなりがちなので、  
+フォルダを分けたりアノテーションを付ける等、分離して実行出来る様にしておきましょう。  
+テストの量が少ないうちは同時に実行しても良いのですが、  
+データベースを使ったテストが増えてくるとテストが終わらない事が問題になります。  
+
+自動化されているテストはなるべく高頻度に実行される事が望ましいのですが、  
+データベースを使ったテストを分離しない事で結果的にテストの実行頻度が下がってしまいます。  
+
+## データベースの設定を定期的に見直す
+テーブル定義のズレは問題として顕在化し易い為、比較的きちんと保守される傾向にあるのですが、  
+バッファキャッシュのサイズ等、パフォーマンスに関わる設定がテスト環境と本番環境ではズレがちです。  
+
+特定のクエリに非常に大きなコストがかかっている事が発見された場合、緊急性の高い問題として管理される事になります。  
+本番環境とテスト環境における設定に大きなずれがあると、問題を再現するだけでも大きな手間がかかる事になります。  
+
+OracleやDB2等商用のRDBは非常に多くの設定自動化機能やチューニングの自動化機能を持っていますし、
+投入可能なハードウェアリソースに制限がある為に、  
+厳密に本番環境とテスト環境の設定を同じにする事は出来無い事が多いのですが、  
+設定を出来る限り近付ける作業を定常作業として開発プロセスに組み込んで下さい。  
+
+
+# 参考書籍
+
+* [レガシーコード改善ガイド](http://www.amazon.co.jp/dp/4798116831/)
+* [データベース・リファクタリング](http://www.amazon.co.jp/dp/4894715007)
+    * [Liquibase](http://www.liquibase.org/)