タイトル長いな。Javaの設定ファイルのようだ。

最近、Javaはウォーターフォールに向いているとか、Web2.0に向いていないとか、Agileに向いていないとか、いろいろ言われていますが、本当にそうでしょうか？

• Javaはウォーターフォールに向いている -> あなたの使用してる言語は大きなウォーターフォールプロジェクトに耐えうる言語ですか？
• Web2.0に向いていない -> (Web2.0じゃないかもしれないけど)Google様はC+,Java,Pythonの順で使用頻度が高いそうです。あなたの言語は？
• Agileに向いていない -> あんなに簡単に大幅なリファクタリングが素早くできる言語（とその環境）があなたの言語にありますか？

一番の謎は、誰もPerlでもphpでもrubyでもなくてPythonがいいじゃん、と言わない所。

Eric3がメジャー３ＯＳで、無料で動作させることが出来ればPythonも相当なリファクタリング性能を秘めているんだけどなぁ。PyQtがなぁ。

Pythonの唯一気に入らないところは、データベースのバインディングスが他の非静的言語と同様にコンパイルを要するところ。

JDBCは素晴らしい。
おーい。ウィンドウズからPostgreSQLを簡単にさわりたいよー（例えばこの用途で一番早く着手＆結果が出るのはJavaでしょ？あ、phpは全部入りか）。

XPではテストファーストで開発を行うことを、TDD(Test Driven Development)と呼ぶ。
生きてまさんや、アジャイルの人の一部はBDD(Behaviour Driven Development)という考え方にしたらよいのではないかと提唱中。
現場ではテストというものは開発後にテスターが行うという認識が未だに強いので、名前を変えようと言うのが趣旨。

主にテストメソッドの名前を次のように変えようということらしい（生きてまさんはドキュメントまで出るといいなと夢想中みたい）。

TDD:testXXXValidUser  （XXXはメソッド名）
BDD:shouldAllowValidUser

テストファーストにアレルギーのない現場にいる身としては、testがshouldに見た目的に代わり「テスト」という対外的なものいいから「仕様」とい う対外的ないいわけに変えられる、ということよりも"test"から"should"に変わったことで「どのメソッドにどういう条件の入力や状態を渡した 際のテスト」から「どういう状態の物はどうされるべき」という仕様として非常にわかりやすい名前が付くであろう事が想定されることこそが利点に思える。

われわれのテストの名前付けに問題があるのかもしれないが、テストメソッドの名前＋メソッド内のアサーションの双方を見ないと１年前に書いたテストの内容がわからないことが多い。
＃次に出てくる問題は、アサーションではなくメソッド名で仕様を表す英語を現場の全員が記述できるかという部分だが、それは置いておく。。。

eclipseで完全に回る実装が現れるまで現場で使うことは出来ないけど（勝手に実装しろ？いやいや）、またこれで一つ開発フローが改善されるような気がする。

私は普段XP(eXtreme Programming)にて開発を行っています。

XPでの開発はテストファーストが基本ですが、アプリケーションの中心にデータベースがいるため、テスト作成の大部分はテストデータ準備コードの記 述に割り当てられていました。

モックオブジェクトではデータベースの正しさについてのテストができませんので、何とかして、あるロジックで処理する直前」のデータが必要となるのです。

テストの要件を満たす準備データの検討に時間がかかるのは仕方ない（それがテストファーストというものでしょ）としても、そ の考え出したデータの投入ロジック記述に大きく時間がかかってしまっていました。
＃特にロジックのデータ永続化にORツールを使用しているため、余計に時間がかかります。

DBTestCaseは、エクセルベースで検討した準備データをDBにインサートし、テスト後にデリートするためのツールです。

具体的には、テーブルとエクセルのシートを対応させ、インサートは左のシートから（シート内は上から）順にインサートをし、デリートは右のシートから（シート内は下から）順にデリートしていくユーティリティです。
インサートとデリートで順序が違うのはFKの影響でデータが消せないことを防ぐためです。自分自身を参照しているテーブルでもインサートができればデリートできるはずです。

• 準備
  

http://sourceforge.jp/projects/dbtestcaseからdbTestCase-0.1.2-src.zipをダウンロードします。
#ソース版にもバイナリが含まれているのでせっかくですからソース版をダウンロードします。
ダウンロードしたファイルを解凍すると、出てきたフォルダの直下に dbTestCase-0.1.2.jar というファイルがあるはずです。 このjarファイルがDBTestCaseのライブラリになります。 また、src/libの中にDBTestCaseが必要とするライブラリが入っていますので、各jarにクラスパスを通してください。

• テーブルの指定の仕方

エクセルのシート名をテーブル名と同じにする必要があります。
全てのシートが順にパースされていきますので、不要なシートは削除しておく必要があります。
下記のようなエクセルの場合、TABLE_AとTABLE_Bというテーブルに対して処理が行われます。

• データの設定の仕方

テーブルに対応したシートにデータを設定します。
シートの一行目に左から詰めて（順番は関係ありません）カラム名を設定していきます。
二行目からはデータの行になります。 空の行は認められませんが、（一行目を含め）背景色をつけたりコメントを追加したりしても問題ありません。
＃またオートフィルタ等POIで正しく読めない機能は使用できません。POIに制限されます。

実際の開発での使用には、「シーケンスを使用せずにデータを設定していくのでテスト環境に関してはシーケンスオブジェクトを1000等から開始し、テストデータは1000未満を設定する」等の取り決めが必要でした。

• 削除キーの指定の仕方

カラム名をBOLDにするだけです。 エクセルのサンプル画像を見てください。
TABLE_BというシートのA1にCOLUMN_AというBOLD文字列がみえるでしょう。
このBOLD文字列のカラム名に対して設定されているデータを削除キーとしてデータを削除します。

• コードの基本

net.yher2.junit.db.DBTestCaseというabstractクラスを継承してテストのベースクラスを作成します。
このクラスは、各データベースや接続テクノロジに対応したjava.sql.Connectionを設定可能なようにabstractクラスになっています。

package net.everes.junk;



import java.sql.Connection;

import java.sql.SQLException;



import net.yher2.junit.db.DBTestCase;



public class DBTestSampleBase extends DBTestCase {

    protected Connection getConnection() throws SQLException {

        //ここにデータベースのコネクションを返すロジックを記述。

        return null;

    }

}

次に上記クラスを継承した各テストクラスを作成します。
Classpathのオブジェクトにエクセルへのパスを設定し、prepare/clearに渡すことによってデータのインサート/デリートが行われます。

package net.everes.junk;



import net.yher2.commons.io.Classpath;



/**

 * 実際のテストクラス

 * @author makoto

 *

 */

public class DBTestSampleA extends DBTestSampleBase {

    private Classpath testDataAPath = null;

    private Classpath testDataBPath = null;



    /**

     * 各テストに必要なデータを用意します。

     */

    protected void setUp() throws Exception {

        super.setUp();

        //クラスパスの通った場所からのエクセルファイルへのパスを設定します。

        testDataAPath = new Classpath("test/data/TestAData.xls");

        testDataBPath = new Classpath("test/data/TestBData.xls");

        prepare(testDataAPath);

        prepare(testDataBPath);

    }

    

    protected void tearDown() throws Exception {

        super.tearDown();

        

        clear(testDataBPath);

        clear(testDataAPath);

    }

    

    public void testSampleA() throws Exception {

        //テストコードを記述

    }

}

• 特殊な使用例

業務用のデータベース設計には、インサートやアップデートの際にトリガーで別テーブルにもデータをインサートするようなものがあります。
そのような場合には、エクセルを複数に分けることで対処することができます。
インサート用のエクセルと別に、トリガーでインサートされるテーブルのデータを削除するためだけのエクセルを用意し、インサート用のエクセルデータ削除前 に利用するのです。

• junit以外のテクノロジとDBTestCaseを使用する

net.yher2.junit.db.TestDataManagerを使用します。
TestDataManagerにjava.sql.Connectionを設定し、DBTestCaseと同様にprepare/clearによってデータのインサート/デリートを行うことができます。