public void SaveStatus(Status newStatus);
上記のメソッドは、いくつかの新しいステータスを DB に保存します。保存操作の成功または失敗を示すブール値フラグのようなものを返す必要があります。
単体テストを書いているときに、何を主張するかSaveStatus()
、成功するかどうかについて質問を受けました。スローされた例外がない場合、単体テストの場合は成功したと見なすことができます。
これに関するベストプラクティスは何ですか?
public void SaveStatus(Status newStatus);
上記のメソッドは、いくつかの新しいステータスを DB に保存します。保存操作の成功または失敗を示すブール値フラグのようなものを返す必要があります。
単体テストを書いているときに、何を主張するかSaveStatus()
、成功するかどうかについて質問を受けました。スローされた例外がない場合、単体テストの場合は成功したと見なすことができます。
これに関するベストプラクティスは何ですか?
失敗を示すために例外をスローします。これにより、アプリケーション ロジックが障害の処理方法を決定するために使用できる障害の詳細を含めることができます。@Hexxagonal の指摘では、コードが頻繁に失敗する場合、これは悪い手法になる可能性がありますが、リポジトリ レイヤーが頻繁に失敗する場合、パフォーマンスは最大の関心事ではありません。
単体テストを行うには、ストレージ メカニズム (データベース?) をモックし、モックで呼び出しを確認します。これにはMoqをお勧めします。
いいえ、そうすべきではありません。これはCommand Query Separationの明らかな違反です。メソッドは、何かを返すか、何らかの状態を変更する必要があります。両方を行うことはできません。
.NET を使用しているため、例外を利用して失敗を示す必要があります。
いいえ、これは意味がありません。void を返す関数から値を返すことは無効です。ただし、ブール値を返すことはできます。呼び出した関数から目的の出力を取得することは、その成功にほかなりません。
いいえ
メソッドの名前は、そのコントラクトを明確に示しています。つまり、ステータスを保存する必要があります。メソッドが何らかの理由で実行できない場合、例外をスローする必要があります。これが OOP の仕組みです。エラーコードまたはフラグを返すと、すべての呼び出し元で次のようになります。
if(xxx.SaveStatus(newStatus)){
// do something
}
else
{
// and here.. what? return another boolean???? Ignore it???? ummmm
}
失敗した場合は、例外が発生しますが、それで十分です。
UT では、新しいステータスが保存されたことをアサートする必要があります。そのためには、たとえばリポジトリまたは使用しているものを使用してデータベース アクセスをモックする必要があります。
成功を気にするなら、はい、成功/失敗を示すブール値を返すことができます。もう 1 つの考えられるオプションは、例外をスローすることです。例外をスローする代わりに、ブール値を戻り値として使用することを好みます。そのメソッド内で例外が発生した場合は、SaveStatus
メソッド内で処理し、false を返します。
この場合に例外をスローしない傾向があるのは、アプリケーションのパフォーマンスに悪影響を及ぼす可能性があるためです。Microsoft の標準では、「定期的に失敗するコードについては、デザイン パターンを使用してパフォーマンスの問題を最小限に抑えることができます」と述べています。