サービスの構成変更をテストする方法は？

新しい構成を追加するときにサービスをテストする最善の方法は何ですか？たとえば、私のサービスは顧客にサービスを提供し、顧客の構成に基づいて、異なるタイプのサービスを提供します。たとえば、顧客が特定の通貨を選択した場合、別の通貨と比較して20％の割引が提供されます。

上記の例は重要ではありません。重要なのは、CI \ CDを行うときに人々がとるアプローチです

割引を計算するロジックはドメイン内にあり、その周りに単体テストがあります。私の質問は、割引を把握するためにさまざまなルールで構成されたマーチャントがいる場合（すべて構成に基づいており、ドメインがそれを解決する場合）、構成を変更する要求が来た場合、どのように確認しますか？

1. もっとテストを書きますか？
2. 単体テストと同じようにテストしませんか？
3. 変更を手動でテストしますか？
4. その他の

私は多くの記事と共にxUnitテストパターンとテスト駆動開発の本を読みましたが、人々がこれをどのように管理するか（サービス内の構成変更と正確性の検証）に遭遇していません。

私はこれが継続的デリバリー・ブックで扱われるのを見ません。

あなたのビジネスロジックはすでにユニットテストによってテストされています。さまざまな構成パラメーターで簡単にテストできますか？そうでない場合は、これら2つを分離する必要があります。

構成<-アプリ->ビジネスロジック

ここでは、たとえば、アプリケーションが構成の読み取りを処理し、パラメーターを使用してビジネスロジックを呼び出すだけです。この方法でユニットテストが簡単です。

統合テストでは、ビジネスロジックではなく、システム全体が連携して動作することをテストします。

必要な条件とテスト可能な結果を​​持つ新しい統合テストを作成します。

テストセットアップの一部は、通貨を設定して特定の割引をテストできる通貨構成にする必要があります。