ユニットテスト、パラメータ化されたテストの詳細な検討。パートI

良い一日、同僚。



パラメータ化されたユニットテストのビジョン、それをどのように行うか、そしておそらくあなたがどのようにしないか（しかしやりたいか）を共有することにしました。



何を正しくテストすべきかについて美しいフレーズを書きたいと思います。テストは重要ですが、すでに多くの資料が私の前で言われ、書かれているので、私の意見では、人々がめったに使用しない（理解する）ものを要約して強調します。に移動します。



この記事の主な目的は、オブジェクトを作成するためのコードでユニットテストを乱雑にするのを防ぐ方法（およびすべきである）と、モック（any（））が十分でなく、そのような状況がたくさんある場合にテストデータを宣言的に作成する方法を示すことです。



mavenプロジェクトを作成し、junit5、junit-jupiter-params、mokitoを追加してみましょう。



完全に退屈にならないように、テストからすぐに書き始めます。TDDの謝罪者が好むように、宣言的にテストするサービスが必要です。



テストHabrServiceTestを作成しましょう。テストクラスフィールドにHabrServiceへのリンクを追加します。

public class HabrServiceTest {

    private HabrService habrService;

    @Test
    void handleTest(){

    }
}

ideを介してサービスを作成し（ショートカットを軽く押すことにより）、フィールドに@InjectMocksアノテーションを追加します。



テストから直接始めましょう。小さなアプリケーションのHabrServiceには、単一のHabrItem引数を受け取る単一のhandle（）メソッドがあり、テストは次のようになります。

public class HabrServiceTest {

    @InjectMocks
    private HabrService habrService;

    @Test
    void handleTest(){
        HabrItem item = new HabrItem();
        habrService.handle(item);
    }
}

HabrServiceにhandle（）メソッドを追加してみましょう。これは、モデレートされてデータベースに保存された後、Habréの新しい投稿のIDを返し、HabrItemタイプを取り、HabrItemも作成します。これで、テストはコンパイルされますが、クラッシュします。



重要なのは、期待される戻り値のチェックを追加したことです。

public class HabrServiceTest {

    @InjectMocks
    private HabrService habrService;

    @BeforeEach
    void setUp(){
        initMocks(this);
    }

    @Test
    void handleTest() {
        HabrItem item = new HabrItem();
        Long actual = habrService.handle(item);

        assertEquals(1L, actual);
    }
}

また、handle（）メソッドの呼び出し中に、ReviewServiceとPersistanceServiceが呼び出され、厳密に次々に呼び出され、1回だけ機能し、他のメソッドが呼び出されなくなったことを確認したいと思います。言い換えれば、このように：

public class HabrServiceTest {

    @InjectMocks
    private HabrService habrService;

    @BeforeEach
    void setUp(){
        initMocks(this);
    }

    @Test
    void handleTest() {
        HabrItem item = new HabrItem();
        
        Long actual = habrService.handle(item);
        
        InOrder inOrder = Mockito.inOrder(reviewService, persistenceService);
        inOrder.verify(reviewService).makeRewiew(item);
        inOrder.verify(persistenceService).makePersist(item);
        inOrder.verifyNoMoreInteractions();

        assertEquals(1L, actual);
    }
}

クラスクラスのフィールドにreviewServiceメソッドとpersistenceServiceを追加し、それらを作成し、makeRewiew（）メソッドとmakePersist（）メソッドをそれぞれ追加します。これですべてがコンパイルされますが、もちろんテストは赤です。



この記事のコンテキストでは、ReviewServiceとPersistanceServiceの実装はそれほど重要ではなく、HabrServiceの実装は重要です。今よりも少し面白くしましょう。

public class HabrService {

    private final ReviewService reviewService;

    private final PersistenceService persistenceService;

    public HabrService(final ReviewService reviewService, final PersistenceService persistenceService) {
        this.reviewService = reviewService;
        this.persistenceService = persistenceService;
    }

    public Long handle(final HabrItem item) {
        HabrItem reviewedItem = reviewService.makeRewiew(item);
        Long persistedItemId = persistenceService.makePersist(reviewedItem);

        return persistedItemId;
    }
}

そして、when（）。then（）構文を使用して、補助コンポーネントの動作をロックします。その結果、テストは次のようになり、緑色になります。

public class HabrServiceTest {

    @Mock
    private ReviewService reviewService;

    @Mock
    private PersistenceService persistenceService;

    @InjectMocks
    private HabrService habrService;

    @BeforeEach
    void setUp() {
        initMocks(this);
    }

    @Test
    void handleTest() {
        HabrItem source = new HabrItem();
        HabrItem reviewedItem = mock(HabrItem.class);

        when(reviewService.makeRewiew(source)).thenReturn(reviewedItem);
        when(persistenceService.makePersist(reviewedItem)).thenReturn(1L);

        Long actual = habrService.handle(source);

        InOrder inOrder = Mockito.inOrder(reviewService, persistenceService);
        inOrder.verify(reviewService).makeRewiew(source);
        inOrder.verify(persistenceService).makePersist(reviewedItem);
        inOrder.verifyNoMoreInteractions();

        assertEquals(1L, actual);
    }
}

パラメータ化されたテストの力を実証するためのモックアップが用意されています。



ハブタイプhubTypeのフィールドをHabrItemサービスのリクエストモデルに追加し、列挙型HubTypeを作成して、いくつかのタイプを含めます。

public enum HubType {
    JAVA, C, PYTHON
}

HabrItemモデルの場合、作成されたHubTypeフィールドにゲッターとセッターを追加します。



HabrServiceの深部にスイッチが隠されているとします。これは、ハブのタイプに応じて、リクエストで不明な処理を実行します。不明なケースをそれぞれテストするテストでは、メソッドの単純な実装は次のようになります。

        
    @Test
    void handleTest() {
        HabrItem reviewedItem = mock(HabrItem.class);
        HabrItem source = new HabrItem();
        source.setHubType(HubType.JAVA);

        when(reviewService.makeRewiew(source)).thenReturn(reviewedItem);
        when(persistenceService.makePersist(reviewedItem)).thenReturn(1L);

        Long actual = habrService.handle(source);

        InOrder inOrder = Mockito.inOrder(reviewService, persistenceService);
        inOrder.verify(reviewService).makeRewiew(source);
        inOrder.verify(persistenceService).makePersist(reviewedItem);
        inOrder.verifyNoMoreInteractions();

        assertEquals(1L, actual);
    }

テストをパラメータ化し、列挙型からランダムな値をパラメータとして追加することで、少しきれいで便利にすることができます。その結果、テスト宣言は次のようになります。

@ParameterizedTest
    @EnumSource(HubType.class)
    void handleTest(final HubType type) 

うまく、宣言的に、そして私たちの列挙のすべての値は間違いなく次のテストの実行で使用されます、注釈にはパラメーターがあり、包含、除外の戦略を追加できます。



しかし、おそらく私は、パラメータ化されたテストが優れているとあなたに確信させていません。追加

元のHabrItemリクエストは新しいeditCountフィールドであり、Habrユーザーが記事を編集する数千回が投稿前に書き込まれるため、少なくとも少しは気に入っていただけます。HabrServiceの奥のどこかに、未知のことを行う何らかのロジックがあると想定します。作成者が試した量に応じて、考えられるすべてのeditCountオプションに対して5つまたは55のテストを記述したくないが、宣言的にテストしたい場合はどうなりますか？1つの場所のどこかに、確認したいすべての値をすぐに示します..。これ以上簡単なものはありません。パラメータ化されたテストのapiを使用すると、メソッド宣言で次のようなものが得られます。

    @ParameterizedTest
    @ValueSource(ints = {0, 5, 14, 23})
    void handleTest(final int type) 

問題があります、宣言的に一度にテストメソッドパラメータに2つの値を収集したいので、パラメータ化されたテストの別の優れたメソッド@CsvSourceを使用できます。これは、単純な出力値（ユーティリティクラスのテストに非常に便利）で、単純なパラメータのテストに最適ですが、オブジェクトがはるかに複雑になった場合はどうなりますか？プリミティブとJavaタイプだけでなく、約10個のフィールドがあるとしましょう。



@MethodSourceアノテーションが役に立ち、テストメソッドが著しく短くなり、セッターがなくなり、着信要求のソースがパラメーターとしてテストメソッドに送られます。

    
    @ParameterizedTest
    @MethodSource("generateSource")
    void handleTest(final HabrItem source) {
        HabrItem reviewedItem = mock(HabrItem.class);

        when(reviewService.makeRewiew(source)).thenReturn(reviewedItem);
        when(persistenceService.makePersist(reviewedItem)).thenReturn(1L);

        Long actual = habrService.handle(source);

        InOrder inOrder = Mockito.inOrder(reviewService, persistenceService);
        inOrder.verify(reviewService).makeRewiew(source);
        inOrder.verify(persistenceService).makePersist(reviewedItem);
        inOrder.verifyNoMoreInteractions();

        assertEquals(1L, actual);
    }

@MethodSourceアノテーションにはgenerateSource文字列がありますが、それは何ですか？これは、必要なモデルを収集するメソッドの名前です。その宣言は次のようになります。

   private static Stream<Arguments> generateSource() {
        HabrItem habrItem = new HabrItem();
        habrItem.setHubType(HubType.JAVA);
        habrItem.setEditCount(999L);
        
        return nextStream(() -> habrItem);
    }

便宜上、nextStream引数のストリームの形成を別のユーティリティテストクラスに移動しました。

public class CommonTestUtil {
    private static final Random RANDOM = new Random();

    public static <T> Stream<Arguments> nextStream(final Supplier<T> supplier) {
        return Stream.generate(() -> Arguments.of(supplier.get())).limit(nextIntBetween(1, 10));
    }

    public static int nextIntBetween(final int min, final int max) {
        return RANDOM.nextInt(max - min + 1) + min;
    }
}

これで、テストを開始すると、HabrItemリクエストモデルが宣言的にテストメソッドパラメータに追加され、テストはテストユーティリティによって生成された引数の数（



この場合は1から10）で実行されます。これは、モデルが引数のストリームにある場合に特に便利です。この例のようにハードコードではなく、ランダマイザーを使用して収集されます（長生きするフローティングテストですが、そうである場合は問題があります）。



私の意見では、すべてがすでにスーパーであり、テストは現在、スタブの動作と期待される結果のみを記述しています。



しかし、これが不運です。新しいフィールド、テキスト、文字列の配列がHabrItemモデルに追加されます。これは、非常に大きい場合とそうでない場合があります。問題ではありません。主なことは、テストを乱雑にしたくない、ランダムデータは必要ない、厳密に定義されたモデルが必要なことです。特定のデータを使用して、テストまたはその他の場所でそれを収集します-私たちは望んでいません。郵便配達員など、どこからでもjsonリクエストの本文を取得し、それに基づいてモックファイルを作成し、テストで宣言的にモデルを作成して、データを含むjsonファイルへのパスのみを指定できれば便利です。



優秀な。 @JsonSourceアノテーションを使用します。これは、相対ファイルパスとターゲットクラスとともに、パスパラメーターを取ります。なんてこった！パラメータ化されたテストにはそのような注釈はありませんが、私はそれが欲しいです。



自分で書いてみましょう。



ArgumentsProviderは、junitの@ParametrizedTestに付属するすべての注釈の処理を担当します。独自のJsonArgumentProviderを記述します。

public class JsonArgumentProvider implements ArgumentsProvider, AnnotationConsumer<JsonSource> {

    private String path;

    private MockDataProvider dataProvider;

    private Class<?> clazz;

    @Override
    public void accept(final JsonSource jsonSource) {
        this.path = jsonSource.path();
        this.dataProvider = new MockDataProvider(new ObjectMapper());
        this.clazz = jsonSource.clazz();
    }

    @Override
    public Stream<Arguments> provideArguments(final ExtensionContext context) {
        return nextSingleStream(() -> dataProvider.parseDataObject(path, clazz));
    }
}

MockDataProviderは、モックjsonファイルを解析するためのクラスであり、その実装は非常に簡単です。

public class MockDataProvider {

    private static final String PATH_PREFIX = "json/";

    private final ObjectMapper objectMapper;

     public <T> T parseDataObject(final String name, final Class<T> clazz) {
        return objectMapper.readValue(new ClassPathResource(PATH_PREFIX + name).getInputStream(), clazz);
    }

}

モックプロバイダーの準備が整いました。アノテーションの引数プロバイダーでもあります。アノテーション自体を追加する必要があります。

/**
 * Source-   ,
 *     json-
 */
@Target({ElementType.ANNOTATION_TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@ArgumentsSource(JsonArgumentProvider.class)
public @interface JsonSource {

    /**
     *   json-,   classpath:/json/
     *
     * @return     
     */
    String path() default "";

    /**
     *  ,        
     *
     * @return  
     */
    Class<?> clazz();
}

やったー。アノテーションを使用する準備が整いました。テスト方法は次のとおりです。

  
    @ParameterizedTest
    @JsonSource(path = MOCK_FILE_PATH, clazz = HabrItem.class)
    void handleTest(final HabrItem source) {
        HabrItem reviewedItem = mock(HabrItem.class);

        when(reviewService.makeRewiew(source)).thenReturn(reviewedItem);
        when(persistenceService.makePersist(reviewedItem)).thenReturn(1L);

        Long actual = habrService.handle(source);

        InOrder inOrder = Mockito.inOrder(reviewService, persistenceService);
        inOrder.verify(reviewService).makeRewiew(source);
        inOrder.verify(persistenceService).makePersist(reviewedItem);
        inOrder.verifyNoMoreInteractions();

        assertEquals(1L, actual);
    }

モックjsonでは、必要な数のオブジェクトを非常に迅速に作成できます。これからは、テストデータの形成のために、テストの本質を損なうコードはありません。もちろん、モックで実行できることはよくありますが、常にそうとは限りません。



要約すると、私は次のように言いたいと思います。私たちは、何年もの間、美しく簡単にできることを考えずに、何年も前と同じように仕事をしていることがよくあります。



PSこの記事は、TDDの概念に関する知識を目的としたものではありません。ストーリーテリングキャンペーンにテストデータを追加して、もう少し明確で興味深いものにしたいと思いました。