SQLおよびデータ操作機能を備えたTDD

私はプロのプログラマーですが、ソフトウェアエンジニアリングの正式なトレーニングを受けたことはありません。私は頻繁にここを訪れているので、可能な限りユニットテストを書く傾向に気づきました。私のソフトウェアがより複雑で洗練されているので、デバッグを支援するための自動化されたテストをお勧めします。

ただし、私の仕事のほとんどは、複雑なSQLを作成してから、何らかの方法で出力を処理することです。たとえば、SQLが正しいデータを返していることを確認するテストをどのように作成しますか？次に、データが制御されていなかった場合（たとえば、サードパーティシステムのデータ）、ダミーデータの連を手書きせずに処理ルーチンを効率的にテストするにはどうすればよいでしょうか。

私が考えることができる最良の解決策は、一緒にほとんどの場合をカバーするデータのビューを作成することです。次に、これらのビューをSQLに結合して、正しいレコードを返しているかどうかを確認し、ビューを手動で処理して、関数などが意図したとおりに動作しているかどうかを確認します。それでも、それは過度で薄汚いようです。特にテストするデータを見つける...

データベースに関連するすべてをテストするための重要なルールは、それをアプリケーションの他の部分から完全に分離することです。

ポートおよびアダプタアーキテクチャは本当に良い例です。データベースは、アプリケーションへのアダプターを介した外部プラグインと見なされます。同じことは、すべてのサードパーティのサブシステムにも当てはまります。アプリがどのように動作し、サードパーティのサブシステムの応答を解釈するかをテストするための唯一の方法は、この個々のサブシステムの応答をスタブすることです。すべてのデータオブジェクトを手動で記述する必要があるとは限りません。データ駆動テストを使用するアプローチを簡単にとることができます。

アプリケーションがデータベースとどのようにやり取りするかをテストするために、たとえばデータベースアダプタを偽造して、インメモリデータベースを使用できます。

データベースクエリをテストします。まず、すべての複雑なクエリを、より簡単で単純で予測可能なクエリに分解する必要があります。ファットクラスまたはファット関数の場合と同じです。Dbunitのようなデータベースのテストに役立つツールがあります。私が時々取る単純なアプローチは、特性評価テストの概念を使用することです。そのため、データベースを既知の状態にし、出力する必要があるすべてのクエリを実行して、出力を場所（ファイル、メモリ）に保存し、この出力を正しいものと見なします。次回の実行では、出力とこれを比較するため、必要な回帰テストが確実に提供されます。実際、最初の出力が正しいことは保証されていませんが、回帰の問題はこの方法で解決できます。クエリが適切に分解されている場合、既知の状態にあるデータベースに対して個別にクエリをテストできます。

データベースは通常、アプリケーションの単体テスト中に偽造される部分であるため、これは興味深い質問です。データベースエンジンのロジック自体がプロバイダーによって十分にテストされることを願っていますが、クエリ、スキーマ、およびストアドプロシージャは、テストして回帰から保護する必要があるコードです。これは多くの場合、TDDではない統合テストに委ねられます。

ビューは、TDDで好まれるテストごとに1つの側面の最初の赤信号、緑信号の自動テストに実際には役立たないため、それを行うのが難しい方法になる可能性があります。また、ビューの場合、コードの前に最初にテストを書くことはできません。より良いアプローチは、ストアドプロシージャを記述し、プロシージャに「アサート」ロジックを追加して（「if」ステートメントを使用するなど）、出力の失敗をテストすることです。ユニットを分離するには、各ユニットテストで1つだけテストする必要があり、SPメソッドの方が適しています。また、SPを使用すると、初期コードを開発し、後でリファクタリング時にリグレッションをテストするときに、それらのスイート全体をスクリプトとして実行できます。

また、テストは繰り返し可能でなければならず、データベースの状態を初期化および破棄して、各ユニットテストの状態が同じであることを確認するためのスクリプトが必要になることに注意してください。

あなたの管理下にないデータについての質問については、それは難しい分野です。偽のデータでモックを作成し、単体テストで可能な限り例外とエッジ条件をテストする方が良いと思います。それ以外の場合は、統合テストのカテゴリにさらに分類されます（これも良いことです）。統合テストの場合、サードパーティのデータに対してテストを実行し、初期出力を生成し、その後のテスト（リファクタリング後など）で、それらの出力が既知の初期出力を繰り返すことを確認できます。

ある時点で、テストデータが必要になります。サードパーティシステムを使用している場合、スキーマは既に作成されていますが、将来の変更に対処する必要があります。アップグレードドキュメントからこれらの変更を取得できることを願っていますが、データベースバージョンを自分で比較することを余儀なくされる場合があります。

予想される結果セットは、データベーステーブルまたは外部ファイル/スプレッドシートに保存できます。CHECKSUMが使用されたり、比較されたりすることもあります。ビュー/プロシージャをテストすると、それらが存在しないため失敗します。次に、少なくとも実行するのに十分なコードでオブジェクトを作成し（SELECT -1 as [wrong_data];）、結果セットと一致しないため失敗します。それらが一致すると、グリーンライトが得られます。

プロジェクトオーナーと協力して、スプレッドシートでレポートのモックを作成し、部分的なデータを作成してみてください（結果データをテストテーブルに入れることもできます）。最初はいくつかのプッシュバックがありましたが、彼らは私がレポートを作成することに気づき、とにかくそれを検証する必要があります。これにより、長期的に時間を節約できました。変更要求を行いたい場合は、スプレッドシートをやり直します。これで、「追加するのはどれくらい難しいでしょうか...」という質問に答えることができます。

データベースプラットフォームがSQL Serverの場合、非常に便利な無料ツールtSQLtがあります。

tSQLtは、Microsoft SQL Server用のデータベースユニットテストフレームワークです。tSQLtは、すべてのエディションでSQL Server 2005（サービスパック2が必要）以上と互換性があります。

データベースレベルでテストを実装することに成功しました。

以下のような重要な要素があります：

• 関係する通常のセットアップを削減する偽のテーブルとビューを使用する機能
• テストはトランザクションで自動的に実行されます（簡単に再実行可能）
• アサーションはテーブル（実際と偽の両方）で比較できるため、データを簡単に変更したかどうかを確認できます。