ビジネスルールを単体テストする方法

Question

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

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

質問：変更される可能性のあるビジネスルールを単体テストする正しい方法は何ですか？

Answer 1

テストでは、コードがビジネスルールに適切に従うことを確認する必要があります。したがって、ビジネスルールを回避するテストや、ビジネスルールコード自体に依存するテストは作成しません。むしろ、ビジネスルールが変更されたら、まず新しいビジネスルールを反映するようにテストを変更し、次にコードがテストに合格しなくなったら、テストに合格するようにコードを修正します。

実行したくないのは、同じビジネスルールの適用方法を変更したときにテストが中断するようにテストを記述することです。言うよりも簡単ですが、基本的にテストしたいのは、コードの実装方法をあまり厳密に指定せずにルールを実装するために最低限必要なことです。ただし、ルールの結果が異なる場合は、最初にテストを変更してから、それに一致するコードを変更する必要があります。

また、テストを特定のデータに結合させたくありません。税の計算を行う場合、テスト対象のクラスが税として5％を使用すると仮定するようにテストを記述するべきではありません。代わりに、税率を提供するようにテストを作成し、計算が正しく行われることを確認する必要があります。おそらく、範囲外の値もキャッチされることを確認するためにテストする値の範囲があるでしょう。この結果の1つは、ハードコーディングされた値を回避し、データの変更に対して生産コードをより柔軟にするのに役立つため、より優れた設計になることです。

Answer 2

同様の設定があります-ただし、ビジネスルールはコンパイルされていますが、構成可能なオプションがあります（異なる場合があります）。ビジネスルールが動作の中心となる方法を変更すると、単体テストが失敗します。これは実際に期待されています-そして良い！つまり、システム全体で予期しない波紋を切り分け、変更に合わせてテストを更新できます。

ルールが外部の場合（何らかのスクリプト言語またはデータベースsproc）、統合テストでそれらをラップし、自動化された実行のために統合テストを結び付ける必要があります。単体テストではなくなりましたが、統合テストもかなり重要であり、単体テストと同様にビジネスルールの変更による予期しない波紋を防ぐのに役立ちます。

Answer 3

ビジネスルールがあり、そのビジネスルールのクライアントがいるようです。これら2つが独立して異なる場合は、それに応じてAPIを設計することをお勧めします。

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

ビジネスルールが変更された場合、古い戦略をそのままにして（後で必要になる場合）、新しいビジネスルールを表すまったく新しい戦略を記述する（および単体テスト）方が合理的です。

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

クライアントを単体テストするときは、特定の戦略の実装に依存せずにクライアントが戦略と正しく対話することを確認するために、テスト二重戦略（モックやスタブなど）に対してそれを行う必要があります。

このようにして、懸念事項を明確に分離し、単体テストを保守可能に保ちます。また、オープン/クローズド原則に従います。

Answer 4

ルールが変更された場合にテストが失敗するのは正しいと思われます-これは予想されることです。

テスト自体でハードコードされた値の代わりにデータフィクスチャを使用する場合、将来のテストの維持を容易にすることができます。たとえば、メソッドがfooを返す必要がある場合、フィクスチャにそれを含めることができます。ビジネスロジックを変更する場合、フィクスチャを変更するだけで、ユニットテスト自体を実行する必要はありません。

もちろん、これはテストするロジックのタイプに大きく依存し、常に適用できるとは限りません。

Answer 5

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