unit-testing - ビジネスルールを単体テストする方法は?

Question

休暇時間が適切に蓄積されていることを確認するために、単体テストが必要です。ただし、休暇時間はビジネス ルールに従って累積されます。ルールが変更されると、単体テストが中断されます。

これは受け入れられますか？メソッドを介してルールを公開し、コードとテストの両方からそのメソッドを呼び出して、単体テストがそれほど脆弱ではないことを確認する必要がありますか?

私の質問は次のとおりです: 変更される可能性のあるビジネス ルールを単体テストする正しい方法は何ですか?

Answer 1

私は同様の設定をしていますが、私のビジネスルールはコンパイルされていますが、設定可能なオプションがあります (あなたのものは異なる場合があります)。ビジネス ルールが動作の中心的な方法を変更すると、単体テストが壊れます。これは実際に期待されていることです。これは、システム全体で予期しない波紋を分離し、変更に合わせてテストを更新できることを意味します。

ルールが外部 (ある種のスクリプト言語またはデータベース sproc) である場合、それらを統合テストでラップし、自動実行のために統合テストを接続する必要があります。もはや単体テストではありませんが、統合テストもかなり重要であり、単体テストと同様に、ビジネス ルールの変更による予期しない波及を防ぐのに役立ちます。

Answer 2

ビジネス ルールがあり、それらのビジネス ルールのクライアントがあるように思えます。これら 2 つが独立して異なる可能性がある場合は、それに応じて API を設計するのが賢明です。

提示されているように、あなたの質問は、戦略パターンを適切に使用することで解決できるように聞こえます。ストラテジーはビジネス ルールを表すため、クライアントを気にすることなく、純粋なコンテキストでそれらを単体テストできます。

ビジネス ルールが変更された場合、(後で再び必要になる場合に備えて) 古い戦略をそのままにしておき、新しいビジネス ルールを表す完全に新しい戦略を作成 (および単体テスト) する方が理にかなっている場合があります。

新しい戦略が完全に完了したら、クライアントで戦略を置き換えることができます。

クライアントの単体テストを行う場合は、テスト ダブル戦略 (モックやスタブなど) に対してテストを実行し、特定の戦略の実装に依存することなく、クライアントが戦略と正しく対話することを確認する必要があります。

このようにして、問題を明確に分離し、単体テストを保守しやすくします。また、オープン/クローズの原則に従います。

Answer 3

私はそれが間違っていると思います 質問 ビジネスルールと単体テストは異なる抽象化レベルにあります。ビジネス ルールは抽象化の最上位レベル (ビジネス モデリング) にありますが、ユニット テストは抽象化の最下位レベルにあるコードのユニットをテストするためのものであるため、ユニット テストを使用してビジネス ルールを検証または検証することはできません。 さらに、分析および設計後のビジネス ルールはコードのいくつかのユニットに影響を与える可能性があるため、ユニット テストを使用してビジネス ルールを検証または検証することはできません。テスト ケースや BDD シナリオを使用して、ビジネス ルールを検証および検証できると思います。