サービスの構成変更をテストする方法は？
新しい構成を追加するときにサービスをテストする最善の方法は何ですか？たとえば、私のサービスは顧客にサービスを提供し、顧客の構成に基づいて、異なるタイプのサービスを提供します。例えば。顧客が特定の通貨を選択すると、別の通貨と比較して20％割引が提供されます。
上記の例は重要ではありません。重要なのは、CI\CDを行うときに人々がとるアプローチです
割引を計算するロジックはドメイン内にあり、その周りに単体テストがあります。私の質問は、割引を把握するために異なるルールで構成されたマーチャント（すべて構成に基づいており、ドメインがそれを解決する）がある場合、構成を変更する要求が来た場合、どのように確認しますか？
- もっとテストを書きますか？
- 単体テストと同じようにテストしませんか？
- 変更を手動でテストしますか？
- その他の
私は多くの記事とともにxUnitテストパターンとテスト駆動開発の本を読みましたが、人々がこれをどのように管理するか（サービス内の構成変更と正確性の検証）に遭遇していません。
私はこれが継続的デリバリー・ブックで扱われるのを見ません。
ビジネスロジックは、単体テストによって既にテストされています。さまざまな構成パラメーターで簡単にテストできますか？そうでない場合は、これら2つを分離する必要があります。
構成<-アプリ->ビジネスロジック
ここでは、たとえば、アプリケーションが構成の読み取りを処理し、パラメーターを使用してビジネスロジックを呼び出すだけです。この方法でユニットテストが簡単です。
統合テストでは、ビジネスロジックではなく、システム全体が連携して動作することをテストします。
必要な条件とテスト可能な結果を持つ新しい統合テストを作成します。
テストセットアップの一部は、通貨を設定して特定の割引をテストできる通貨構成にする必要があります。