2

CompanyService の findCompany() メソッドをテストする Test クラスに、次の 4 つのテストを作成しました。

@Test
public void findCompany_CompanyIdIsZero() {
    exception.expect(IllegalArgumentException.class);
    companyService.findCompany(0);
}
@Test
public void findCompany_CompanyIdIsNegative() {
    exception.expect(IllegalArgumentException.class);
    companyService.findCompany(-100);
}
@Test
public void findCompany_CompanyIdDoesntExistInDatabase() {
    Company storedCompany = companyService.findCompany(100000);
    assertNull(storedCompany1);
}

@Test
public void findCompany_CompanyIdExistsInDatabase() {
    Company company = new Company("FAL", "Falahaar");

    companyService.addCompany(company);

    Company storedCompany1 = companyService.findCompany(company.getId());
    assertNotNull(storedCompany1);
}

私の理解では、これらのうち最初の 3 つは単体テストです。findCompany() メソッドの動作をテストし、メソッドがさまざまな入力に対してどのように応答するかを確認します。4 番目のテストは、同じクラスに配置されていますが、実際には統合テストのように思えます。後で見つけることができるように、最初に会社をデータベースに追加する必要があります。これにより、外部依存関係 (addCompany() およびデータベース) が導入されます。

私は正しいですか？はいの場合、既存のオブジェクトを見つけるための単体テストをどのように行うべきですか? サービスを「見つける」ためにモックするだけですか？それはテストの意図を殺すと思います。

ここでのガイダンスに感謝します。

4

2 に答える 2

1

私はそれをこのように見ています：あなたがここでテストしている「ユニット」はですCompanyService。この意味で、すべてのテストは私には単体テストのように見えます。ただし、サービスの下に、このテストでも実行されている別のサービス（データベースについて言及している）がある可能性がありますか？これは統合テストで少し境界線を曖昧にし始めるかもしれませんが、それが重要かどうかを自問する必要があります。そのような基礎となるサービスをスタブアウトすることができます。

  1. 基盤となるサービスのセットアップや使用が遅く、単体テストが遅すぎます。
  2. このテストの動作が基盤となるサービスの影響を受けないことを確認する必要があります。つまり、このテストは、にバグがある場合にのみ失敗するはずですCompanyService。

私の経験では、基盤となるサービスが十分に高速であれば、単体テストがそれに依存していることについてあまり心配する必要はありません。ユニットテストに少し統合が漏れてもかまいません。統合の範囲が広くなり、問題が発生することはめったにありません。問題が発生した場合は、いつでも戻ってスタブを追加し、分離を改善できます。

于 2013-02-25T23:15:33.050 に答える
1

[1,2,3,4] は、ユニットベース (モック | モックではない) および統合ベースのテストである可能性があります。何をテストするかによって異なります。

  • モッキングを使用する理由 Jason Sankeyが言ったように...層の下にないサービス層のみをテストします。
  • モッキングを使用する理由 ビジネス ロジックにはさまざまな形式があります。したがって、 1 つのサービス メソッドに対して複数のテストを記述できます。個人の作成 (住所なし - 例外、銀行口座なし - 例外、個人に null 以外の属性が入力されていない - 例外)。

すべての可能性のある例外状態 (住所なし、銀行口座なしなど) をテストするために、各テストでデータベースが要求されたと想像できますか? すべての例外状態をテストするために、データベースをいっぱいにする作業が多すぎます。モック化されたオブジェクトを使用しないのはなぜですか。期待値を含まない「不自由な」オブジェクトのように振る舞います。各テストは、独自の「不自由な」モック オブジェクトを構築します。

さまざまな状態のモック === 各テスト メソッドは 1 つの状態のみをテストするため、テストは可能な限り単純になります。これらのテストは、明確で理解しやすく、保守も簡単です。これは、テストを作成する場合に達成したい目標の 1 つです。

于 2013-02-27T13:52:59.320 に答える