複雑な意思決定グラフをモデル化するためのパターンの設計
現在、入力パラメーターに基づいて副作用を作成するコードを作成しています。約10の入力パラメーターと約6つの利用可能な副作用があります。入力パラメーターに基づいて、選択した副作用-1つまたは複数-は異なります。
すべての入力パラメーターは基本的にコンテキストであるため、私は最初にコンテキスト/仕様フレームワークを使用してこのコードテストの開発を開始しました。
これまでの結果のコードは、深くネストされたif-else構造です。
私はこれまでに約30％を実装しており、コード（およびテスト）は非常に複雑になり、扱いにくく、理解しにくくなっています。これが正しいアプローチであることを疑っているほどです。
主な問題は実際にはテストです。これは、ネストされた入力パラメーターの一部と、結果として生じる副作用について、条件を繰り返し続けているためです。
このような「デシジョングラフ」を作成してテストするためのデザインパターンはありますか？
入力パラメータは固定値ではないことに注意してください。ロジックの多くは相対的です。つまり、入力パラメーター1が入力パラメーター2より小さい場合です。
私のテストからの現在の出力はここで見ることができます： https://cloud.fire-development.com/f/12bcba0439/?raw=1
繰り返しがたくさんあり、実際に何をしているのかを判断するのが難しいことがわかります。
実装の観点から見ると、Martin＆Ericの Specification パターンが役立ちます。可能であれば、ルールを細分化し、小さいルールにグループ化し、「複合仕様の論理式」を使用してそれらを収束させてください。このようにして、個々の小さな論理ユニットを1つずつテストできます。
また、RedhatのDroolなど、意思決定DSL用の市販の市販のソリューションもあります。
テストに関しては、分解とは別に、 Data-Driven Test が問題に非常に適しているようです。このパターンを使用するシナリオは次のとおりです
「本質的に同じテストをわずかに異なるシステム入力で行い、実際の出力がそれに応じて変化することを確認する」
また、Fitなど、テスト領域には多くの商用またはオープンソースソリューションがあります。