今日、MySQLでストアドプロシージャの単体テストフレームワークを作成することを思いつきました。完全なアイデアは私のブログの最近の投稿に書かれています。つまり、手順のテストを自動化し、標準化された方法を使用して手順をテストしたいと考えています。ユニットテストは広く文書化されており、そこには無数のXUnitフレームワークがあります。MySQL(または他のデータベース)用に1つ作成してみませんか。もちろんオープンソースになります。どう思いますか?それは愚かで、愚かで、不必要であるか、それとも何ですか?または、SQLで一般的なデータベースフレームワークを作成することもできます。うーん、本当に誰かと話し合って、考えやアイデアを集めたいです。
7 に答える
SQLServerのテストフレームワークはすでに1つあります-TSQLUnit。多分あなたはそれからいくつかの有用な情報を得ることができます。
はい、素晴らしいアイデアです。私はpgTAPでかなりの成功を収めてきました。テスト駆動データベースの開発と、既存のプロシージャを効果的にリファクタリングできるようにするためのテストの作成の両方で、これを多くのプロジェクトで使用しました。
MySQLにそのようなものがあるかどうかよく尋ねられます。多分あなたは今までに何かを書いたのですか?
私はデータアクセス層を単体テストする傾向があります。適切なデータを使用して適切なデータベースをセットアップする必要があるため、これは常にお尻の痛みです。(RedGateのデータジェネレーターのように)セットアッププロセスを簡単にするのに役立つデータジェネレーターがあります。
DALをテストするだけの背後にある私の考えは、基本的に、単体テストについて心配する必要はないと思う、追加された.NetDBコードを使用してストアドプロシージャ自体をテストしているということです。このようにして、単体テスト用にすでに持っているすべてのツールとプロセスを活用できます。(IMHO)既存のツールと同等にうまく実行できるもののために別のフレームワークを開発するのは大変な努力のようです。
でも私は心を開いています。私が見落としている利点がある場合は、教えてください。
乾杯、V
利点の1つは、テストが、メインアプリケーションの外部の専門のデータベース開発者によって維持され、記述および実行されるストアドプロシージャと同じ環境で記述されることです。アプリケーション開発者がリレーショナルデータベースのプログラミングのマスターである必要はなく、データベース開発者が最新のアプリケーション開発言語をマスターする必要もありません。これで、すべてのテストが完了しました。データベース用にSQLを記述し、社内で開発したアプリケーションの外部で実行してみませんか。
多層アプリケーションを開発している場合は、各部分を分離して個別にテストするのが理にかなっています。
TST を試す: http://tst.codeplex.com
データベースには、テストを価値のあるものにするのに十分なロジックがないはずです。