4

最近、特別な形式のファイルからデータベースにデータをインポートできる単純なユーティリティを作成するタスクがありました。いくつかのクラスでコンソール アプリケーションを実装しました (プログラム クラスはビジネス ロジック クラスで動作し、ビジネス ロジック クラスはデータ アクセス クラスで動作します)。すべて問題なく動作しますが、今は単体テストを作成してアプリケーションをリファクタリングすることを考えています (これまで実際の単体テストを作成したことはなく、かなり前に一連の統合テストを作成しただけなので、このアプリケーションは練習に最適な分野であると思います) .

ここに問題があります。データ アクセス クラスが静的に作成されているため、モックを作成することができず、その結果、実際の単体テストが作成されます。これを修正するには、インターフェイスを作成してデータ アクセス クラスに実装する必要があります。また、そのインターフェイス タイプのパラメーターを受け入れるビジネス ロジック クラスにコンストラクターを追加する必要があります。したがって、これは、アプリケーションの Main() メソッドでデータ アクセス クラスを作成することになることを意味し、何かがこれが最善のアプローチではないことを教えてくれます (エントリ ポイントがいくつかのデータ アクセスについて知っている必要がありますか? チェーンがもっと長いか、いくつかのチェーンが必要ですか?)。IoC コンテナーを使用できることはわかっていますが、これはコンテナーを使用するには単純すぎるアプリケーションだと思います。

ありがとう！

4

3 に答える 3

6

インターフェイスを作成し、それをデータ アクセス クラスに実装する必要があります。また、そのインターフェイス タイプのパラメーターを受け入れるビジネス ロジック クラスにコンストラクターを追加する必要があります。したがって、これは、アプリケーションの Main() メソッドでデータ アクセス クラスを作成することになることを意味し、何かがこれが最善のアプローチではないことを教えてくれます (エントリ ポイントがいくつかのデータ アクセスについて知っている必要がありますか? チェーンがもっと長いか、いくつかのチェーンが必要ですか?)

それどころか！少なくともテスト容易性の観点からは、これが最良のアプローチです。

ビジネス ロジック層をテスト可能にする唯一の方法は、考えていることを正確に実行して、データ アクセス層から分離することです。

トップレベルのアプリケーションは、お金が止まる場所です。具体的なデータ アクセス クラスが何であるかを知る必要がある唯一のコンポーネントです。

チェーンがはるかに長いか、複数のチェーンがある場合、それは大したことではありません (ただし、手に負えなくなった場合は、いくつかのアプリケーション レイヤーを折りたたむことを検討することをお勧めします)。が に依存し、 が に依存し、 が に依存し、 が に依存している(これも に依存している)Model-View-Presenterアプリの の潜在的なコードを考えてみましょう。ViewPresenterCustomerServiceRepositoryAccountingServiceRepository

public CustomerView() {
    IRespository       repository        = new ConcreteRepository();
    IAccountingService accountingService = new ConcreteAccountingService(repository);
    ICustomerService   customerService   = new ConcreteCustomerService(accountingService, repository)
    this._Presenter = new CustomerPresenter(customerService);
}

最後に、依存性注入コンテナーを使用したくない場合は使用する必要はありません (それらのいくつかは驚くほど軽量です) - 手作業による依存性注入は、あちこちで自分自身を繰り返し始めるまで (または構成したいことがわかるまで) うまく機能します実行時の依存関係)。

于 2009-09-21T17:11:13.080 に答える
1

LINQ to SQL を使用していると仮定すると、リポジトリ パターンを使用して、後でモックできるインターフェイスに DataContext をラップし、単体テストを可能にすることができます。

この主題に関する記事がインターネット上にいくつかあります。ここにその 1 つがあります 。

于 2009-09-21T15:16:26.370 に答える
0

簡単な解決策を次に示します。データ アクセス クラスを直接呼び出す代わりに、ヘルパー メソッドを使用します。

  public void insert (...) {
      DataAccess.insert (...);
  }

これらの呼び出しをオーバーライドできるようになりました。次のようにテストを分割することをお勧めします。

  1. DataAccess正しいパラメーターを取得したときに正しいことを行うことを確認するいくつかのテストを作成します。

  2. モックアップ テストでは、 に送信されたパラメータを収集するだけinsert()です。絶対に電話しないでくださいDataAccess。

#1 のテストでは、DB へのデータの書き込みが機能することを確認し、#2 のテストではDataAccess、正しい値で呼び出すことを確認します。後者のテストは非常に高速に実行されるため、特殊なケースなどのテストが容易になります。

常に #1 からテストを実行する必要もありません。DataAccessリリース中またはリリース前に何かを変更した場合のみ。これにより、テストが効率的かつ快適になります。

于 2009-09-21T14:53:22.257 に答える