4

問題のドメインが高度に相互に関連するドメイン オブジェクトによって表されるアプリケーションがあります。モデルに順序を課すのに役立ついくつかの集約ルート オブジェクトにドメインを分割しましたが、これらの集約ルートのインスタンスを作成するには、参照される多数のサポート オブジェクトを作成する必要があるため、単体テストの前提条件を調整するのは困難です。

私は、外部依存関係を必要とせずに (そして理想的には大量のコードを書かずに) アプリケーションを実行する、反復可能で分離された単体テストを作成したいと考えています。

これらは私の選択肢だと思います。好み、または他の提案はありますか？

  1. プロジェクト データベースをセットアップし、既知のデータをそこに挿入するビルド スクリプトを記述します。これに対して単体テストが実行されます。これは、外部依存関係 (したがって、真の単体テストではない) を導入するだけでなく、さらに多くの潜在的な失敗をもたらすため、私が最も好まないオプションです。また、障害がデータ アクセス コード内にある可能性があるため、テスト対象のビジネス機能を分離することもできません。

  2. 単体テストが実行される既知の状態でドメイン オブジェクトを作成する、再利用可能なファクトリを作成します。これはうまく機能しますが、多くのボイラープレート コードを作成する必要があるため、モデルが変更された場合に変更する必要があることを意味します。

  3. (現在の方法) テスト プロジェクトでチェックインされるファイルに集計ルート オブジェクトのバイナリ シリアル化を作成します。単体テストは、テストのためにそれらを逆シリアル化します。これの欠点は、基になる型が変更された場合、逆シリアル化が失敗し、すべてのシリアル化されたファイルを再作成する必要があることです。

  4. 思い切って、ソリューションにチェックインしてテスト時に逆シリアル化できる XML ファイルにグラフをシリアル化するカスタム シリアライザーを作成します。2と同様、前もってボイラープレートのコードをたくさん書く必要がありますが、モデルが変更された場合、シリアル化された状態をテキスト エディターで簡単に編集できるため、メンテナンスが容易になります。

  5. UR DOIN IT RONG. ドメイン オブジェクトの参照性が非常に高いという事実が主な問題です。単純化します。

ありがとう！

4

2 に答える 2

3

プロジェクトデータベースをセットアップし、そのデータベースに既知のデータを挿入するビルドスクリプトを記述します。これに対して、単体テストが実行されます。これは、外部依存関係（したがって、真の単体テストではない）と、さらに多くの潜在的な障害をもたらすため、私の最も嫌いなオプションです。また、障害がデータアクセスコード内にある可能性があるため、テスト対象のビジネス機能を分離しません。

「ユニットではない統合」はマイナーな問題です（特に「テストするかどうか」と比較した場合）、私はそれについて心配しません。このアプローチには、他にももっと深刻な問題があります。

  • スクリプトを書く。SQLを手作業でコーディングすることになり、特にモデルが複雑な場合は、多くの規律が必要になります。タイプミスは苦痛であり、問​​題をデバッグ/検出するのは困難です。IDE/ツールも考慮する必要があります。
  • モデルが変更されると、それらのSQLスクリプトを修正することになります。これにより、タイプミス、エラーの特定が困難など、IDEサポートの欠如などの同じ問題が発生します。

全体として、このアプローチは保守性の点でコストがかかります。

ユニットテストが実行される既知の状態のドメインオブジェクトを作成する再利用可能なファクトリを作成します。これはうまく機能しますが、多くの定型コードを記述する必要があるため、モデルが変更された場合に変更する必要があります。

適切なアプローチでは、このプロセスを容易にするライブラリを調査する必要があります（ヒント：AutoFixture、NBuilder）。

（現在の方法）テストプロジェクトでチェックインされるファイルに、集約ルートオブジェクトのバイナリシリアル化を作成します。単体テストは、テストのためにそれらを逆シリアル化します。これの欠点は、基になるタイプが変更された場合、逆シリアル化が失敗し、すべてのシリアル化されたファイルを再作成する必要があることです。

ビルドスクリプトの場合と同じ問題-変更には費用がかかります。

それを吸い上げて、ソリューションにチェックインし、テスト時に逆シリアル化できるXMLファイルにグラフをシリアル化するカスタムシリアライザーを作成します。2と同様に、これは多くの先行ボイラープレートコードを記述することを意味しますが、モデルが変更された場合にシリアル化された状態をテキストエディターで簡単に編集できるため、メンテナンスが容易です。

これは基本的に2番目のソリューションと同じソリューションですが、中間者としてXMLを使用します。なぜ余分なレイヤーを追加するのですか？

UR DOINITRONG。ドメインオブジェクトが非常に参照性が高いという事実が主な問題です。単純化してください。

かなりありそうもない。ドメインオブジェクトの性質上、複雑になる傾向があります。

結論

このような問題に対する迅速で汚い回避策はありません。複雑なドメインとは、ある時点で追加の作業を行う必要があることを意味します。シリアル化ベースのソリューション（1、3、4）は、今では簡単に思えるかもしれませんが、変更が導入された瞬間に、前述の余分な作業を延期するだけです。ほとんどすべての場合、変更に対する柔軟性と準備が整っています（適切に実行された場合、2番目のソリューションのみが提供します）。

于 2013-01-19T14:19:08.273 に答える
0

あなたが話している問題は、データがdomain-object-graphに散在していることです。

請求書の価格を計算する場合は、商品価格、税情報、顧客固有の割引、配送固有の送料定数などが必要です。

この複雑さを処理するための1つの戦略は、ロジックを分離して、実際の計算からこれらの詳細値を取得することです。

計算は、多くのパラメーターを持ち、他のドメインオブジェクトへの依存を最小限に抑えた内部メソッドです。これは、オブジェクトグラフに依存しなくなったため、簡単にテストできます。

もう1つの戦略は、複雑な計算をドメインから他のサービスインターフェイスに依存する個別のサービスレイヤーに移動することです。これらのサービスインターフェースをテストするために、モックに置き換えることができます。

于 2013-01-19T16:14:03.683 に答える