データベーステスト：UIだけをテストしているエンジニアが見落とすもの
Rui Li
多くの自動テストスイートはインターフェースをテストします。フォームの送信、ボタンのクリック、ページの読み込み、APIのレスポンス。これらのテストは価値あるものですが、特定の点において不完全です。アプリケーションが「表示する」ものを検証するだけで、「保存する」ものを検証していないという問題です。
データベーステストは、アプリケーションのデータ層が正しく動作しているかを検証します。正しいレコードが正しい値で作成・更新・削除されているか、制約が適切に適用されているか、トランザクションがアトミックに完了しているか、そして操作後のデータベース状態がアプリケーションロジックの意図と一致しているかを確認します。
UIのみのテストで見落とされるもの
UIが表示するものとデータベースが保存するものの間のギャップには、最もコストの高いバグが潜んでいます。
フォームの送信が成功確認メッセージを表示する一方で、不正なデータをデータベースに書き込む場合があります。UIテストはパスします。しかしデータベースのレコードは誤っています。フォームを送信したユーザーは、データが正しく保存されなかったことを、後で戻ってきてデータが消えているか破損していることを発見するまで気づきません。
カスケード効果も同様に見落とされやすい問題です。対象レコードを正しく更新する操作が、関連レコードを誤って変更するカスケードを引き起こす場合があります。UIにはプライマリな変更が表示されますが、二次的な影響は下流の機能が破損した状態を明らかにするまで不可視のままです。
ソフトデリートは、微妙な障害の持続的な原因となります。レコードを削除するのではなく削除済みとしてマークするアプリケーションは、ソフトデリートされたレコードがクエリに表示されないこと、カスケードロジックが正しく処理されること、そして復元操作によって完全なレコード状態が元に戻ることを検証する必要があります。これらはUIレイヤーでは一切確認できません。
制約テストのギャップ
データベース制約（ユニークインデックス、外部キー関係、チェック制約、NOT NULL要件）は、ストレージレイヤーでデータベースが適用するデータ整合性の保証です。アプリケーションコードが制約違反を正しく処理するかのテストと、制約自体が正しく定義されているかのテストは別物です。
両方をテストする必要があります。ユニーク制約違反を握りつぶしてユーザーに通知しないアプリケーションは、エラーなしに重複レコードを受け入れているように見えます。スキーマから外部キー制約が欠落していると、下流のクエリを破壊する孤立レコードが生まれます。
AIテストワークフローへのデータベースアサーションの統合
TestSpriteのテストフレームワークは、エンドツーエンドのテストフローの一部としてデータベース状態の検証をサポートしています。データベースへの書き込みが期待されるテストアクションの後、テストはUIが期待どおりの確認メッセージを表示することだけでなく、正しい値でデータベースレコードが存在することもアサートします。
このアプローチにより、UIの検証はパスしながらも静かにデータ状態を破壊するという種類の障害を検出できます。これは本番環境での診断が最も困難な障害のひとつです。症状（誤ったデータ）が原因（静かに失敗したか誤った値を書き込んだ書き込み処理）から時間的・文脈的に切り離されているためです。
スキーママイグレーションテスト
データベーススキーマのマイグレーションは、アプリケーションレベルのテストとは別に、独自のテストカバレッジが必要です。小規模なデータセットの開発データベースで正常に実行されるマイグレーションが、数年分のデータが蓄積された本番データベース、非推奨フォーマットのレガシーレコード、開発環境では発生しなかったエッジケースに対しては失敗したり誤った結果を生じたりする可能性があります。
本番環境を代表するデータ（匿名化済みまたは合成データ）に対してマイグレーションをテストしてから本番環境に適用することは、不便であることを理由にほとんどのチームがスキップしている、最も費用対効果の高いプラクティスのひとつです。これにより防げるインシデントは不釣り合いなほど深刻です。データ損失、レコードの破損、タイムプレッシャーの下でのロールバックを必要とするデプロイ失敗などが挙げられます。