c# - そのようなエッジケースの統合テストを行う必要があります

Question

SQLテーブルのNAMEフィールドは、他のフィールドを組み合わせたものです。

1_2_UserId_CreationDatetime例：1_2_domain \ Elisa_15-07-2012 08:30:57

私のNAMEフィールドには、同じ名前が許可されていないことを表す一意の制約があります。主キーはautoincidです。

新しいデータ行が挿入されたときにUniqueConstraintExceptionをキャッチすることは理にかなっていますが、ユーザーがWebアプリケーションに2回ログインし、同じ秒でボタンを押す必要があるため、実際には同じ名前を2回持つことはできません。 。

私は本当にそのようなシナリオをテストする必要がありますか？

アップデート

それがワークフローです：

ユーザーは、テンプレートとリリースのリストから選択して、新しいテストプランを作成します。

次に、テストプランがreleaseName_templateName_UserId_CreationDateとともに保存されます

ただし、4つのフィールドには、releaseId、templateId、UserId、およびCreatedDateが保存されます。

ユーザーをNAMEとして表示するには、releaseIdとtemplateId（どちらもint`s）は意味がありません。

したがって、4つのpart_namesすべてを使用してNAMEを保存します。

この複合NAMEフィールドの別の設計代替案は、テストプランテーブルからNAMEフィールドを削除することです。すべてのテストプランをロードするときに、すべてのreleaseIdとtemplateIdのreleaseNameとtemplateNameを取得しようとします。

どう思いますか？エッジケースについての私の元の質問も覚えておいてください...

Answer 1

私はそれをテストします。例外がどのように発生するかは、ある程度無関係です。システムの使用パターンは、時間の経過とともに変化する可能性があります。

記録として、あなたは第一正規形に違反している可能性があります。違反している場合は、多くの考えと分析を行わない限り、そのアプローチを放棄することをお勧めします。私は完全なテーブルを見なければならないでしょう。それらの他の列が同じテーブルにある場合、あなたは間違いなくそうです。これらの複数の列に一意の制約を追加するか、これらの列を複合主キーとして使用する可能性があります（それが本当に意図している場合）。また、これらのフィールドの一部を他のテーブルに移動する必要がある場合もあります。私は本当にあなたのデザインを確実に見なければならないでしょう。

Answer 2

テストを説明した方法では、テストはRDBMSが正しく機能していることをテストするだけのように聞こえますが、実際に気にする必要はありません（RDBMSが機能しない場合は、別のユーザーを使用します）。それか、スキーマをテストしています。これに多くの価値があるかどうかはよくわかりません。ユニットテストが失敗した場合、あなたは何をすることを期待しますか？スキーマが正しいことを確認しますか？正しい場合はどうしますか？スキーマが期待値に変更されていないことを検証するために他の多くのテストを実行している場合は、このようなテストが理にかなっている可能性があります。そうでなければ、それは私にはあまり意味がありません。

これで、アプリケーションがこのUniqueContraintExceptionを処理し、特定の処理を実行した場合、アプリケーションが期待どおりに実行されることを確認するためのテストは理にかなっています。