私は休暇を適切に積み重ねていることを確認するために単体テストが必要です。しかし、ビジネスルールに従って休暇が積算されます。ルールが変更された場合、単体テストは中断します。テストビジネスルールのユニット化の仕方は？
これは受け入れ可能ですか？メソッドを使ってルールを公開し、コードとテストの両方からそのメソッドを呼び出して、単体テストが脆弱でないことを確認する必要がありますか？
私の質問は、単位テストビジネスルールを変更する正しい方法は何ですか？
テストでは、コードがビジネスルールに正しく従うことを確認する必要があります。したがって、私はビジネスルールを巡って行ったり、ビジネスルールコードそのものに依存するテストを書いていません。むしろ、ビジネスルールが変更されたときは、新しいビジネスルールを反映するようにテストを変更してから、コードがテストに合格しなくなったら、テストに合格するようにコードを修正します。
何も起こりたくないのは、同じビジネスルールの適用方法を変更したときにテストが中断するようにテストを書くことです。これは簡単なことですが、本質的にテストするのは、コードをどのように実装するかをあまり厳密に指示せずにルールを実装するために最低限必要なものです。ただし、ルールの結果が異なる場合は、まずテストを変更してから、それに合わせてコードを変更する必要があります。
また、テストを特定のデータに結合したくない場合もあります。税計算を行うときに、テスト対象のクラスが税金として5％を使用すると仮定してテストを書くべきではありません。代わりに、税率を提供するようにテストを書いて、計算が正しく行われていることを確認する必要があります。おそらく、範囲外の値が捕捉されていることを確認するためにテストするための値の範囲があります。その結果、ハードコーディングされた値を避け、データの変更に対してより柔軟なプロダクションコードを作成するのに役立ちますので、より優れたデザインが得られます。
私は同様の設定をしていますが、私のビジネスルールはコンパイルされますが、設定可能なオプションがあります（あなたとは異なる場合があります）。ビジネスルールが動作する中核的な方法を変更すると、私の単体テストは中断します。これは実際に期待されています。これは、システム全体で予期せぬリップルを分離し、その変更に合わせてテストを更新できることを意味します。
ルールが外部（何らかの種類のスクリプト言語またはデータベースsproc）の場合、統合テストでラップし、統合テストを自動実行する必要があります。単体テストではありませんが、統合テストもかなり重要です。ユニットテストと同じように、ビジネスルールの変更による予期しない波紋の防止に役立ちます。
ルールが変更された場合、テストが失敗することは間違いないと思われます。
テスト自体にハードコードされた値の代わりにデータフィクスチャを使用すると、将来的にテストを維持しやすくすることができます。たとえば、メソッドがfooを返す必要がある場合は、フィクスチャにそのメソッドを含めることができます。ビジネスロジックを変更するときは、単にフィクスチャを変更するだけで、ユニットテスト自体を行う必要はありません。
もちろん、これはテストするロジックの種類によって大きく異なり、必ずしも該当するとは限りません。
あなたはビジネスルールを持っているように聞こえ、ビジネスルールのクライアントを持っているようです。これら2つが独立して変更できる場合は、それに応じてAPIを設計することをおすすめします。
あなたの質問は、戦略パターンを適切に使用して解決できるように聞こえます。戦略はビジネスルールを表しているため、クライアントについて心配することなく、それらを純粋なコンテキストでテストできます。
ビジネスルールが変更された場合、古いストラテジをそのまま残しておくことができます（後で再度必要な場合に備えて）。新しいビジネスを表す全く新しいストラテジーを書くルール。
新しい戦略が完全に完了したら、クライアントの戦略を置き換えることができます。
クライアントを単体テストするときは、クライアントが特定の戦略の実装に依存することなく、戦略と正しく対話することを確認するために、Test Double Strategy（MockやStubなど）に対して行う必要があります。
このようにして、懸念事項を明確に分離し、単体テストを維持し続けることができます。また、オープン/クローズド原則に従います。
私はそれが間違った質問だと思う ビジネスルールと単体テストは異なる抽象化レベルにあります。 ビジネスルールは抽象化の最上位レベル（ビジネスモデリング）ですが、単体テストは最も抽象度の低いコードの単位をテストするためのものです。ビジネスルールの検証や検証に単体テストを使用することはできません。 さらに、分析と設計後のビジネスルールはいくつかのコード単位に影響する可能性がありますので、はユニットテストを使用してビジネスルールを検証または検証することはできません。 私は、テストケースまたはBDDシナリオを使用して、ビジネスルールの検証と検証ができると思います。
ルールを変更すると、予想される結果が変更されます。つまり、これまでに使用されていたいくつかの正の単体テストが失敗し、（エラーを検出することによって）渡すために使用されたいくつかの否定的なテストが失敗する可能性があります。単体テストは現在のルールのみを検証できます。ルールが変更される前にルールに対するすべての変更を検証することはできません。ルールが変わると、単体テストも必要になるかもしれません。 –