最終的にテストを書き始めて後悔しない方法

新しいプロジェクトに来て、私は定期的に次のいずれかの状況に遭遇します。

1. テストはまったくありません。
2. テストはほとんどありませんが、ほとんど書かれておらず、継続的に実行されません。
3. テストは存在し、CI（継続的インテグレーション）に含まれていますが、良いことよりも害が大きくなります。

残念ながら、適切なスキルがない場合にテストの実装を開始しようとする深刻な試みにつながるのは、後者のシナリオです。



現在の状況を変えるために何ができますか？ テストを使用するという考え方は新しいものではありません。 同時に、ほとんどのチュートリアルは、フクロウを描く方法についての有名な図に似ています：JUnitを接続し、最初のテストを作成し、最初のモックを使用して実行してください！ そのような記事は、どのテストを書く必要があるか、何に注意を払う価値があるか、そしてこれらすべてをどのように生きるかについての質問には答えません。 ここから、この記事のアイデアが生まれました。 誰にとってもこの道を促進するために、さまざまなプロジェクトでテストを実装した経験を簡単に要約しようとしました。









このトピックに関する入門記事は十分にあるため、繰り返し説明することはせず、反対側から行こうとしません。 最初の部分では、テストには追加コストのみが伴うという神話を覆します。 品質テストの作成が開発プロセスを加速する方法が示されます。 次に、小規模プロジェクトの例で、このメリットを実現するために従うべき基本原則とルールを検討します。 最後に、最後のセクションでは、具体的な実装の推奨事項を示します。テストを開始するときに典型的な問題を回避する方法とは対照的に、開発を大幅に遅くします。



私の主な専門分野はJavaバックエンドであるため、例では次のテクノロジースタックが使用されます：Java、JUnit、H2、Mockito、Spring、Hibernate。 さらに、この記事の大部分は一般的なテストの問題に当てられており、その中のヒントはより広範なタスクに適用できます。



ただし、注意してください！ テストは非常に中毒性があります。テストの使用方法を学ぶと、テストなしでは生きられなくなります。

テストと開発速度

テストの実装を議論する際に生じる主な質問：テストを書くのにどれくらい時間がかかり、どのような利点がありますか？ テストは、他の技術と同様に、開発と実装に真剣に取り組む必要があるため、最初は大きなメリットは期待できません。 時間コストについては、特定のチームに大きく依存しています。 ただし、コーディングの追加コストの20〜30％未満を正確に計算しないでください。 少なくても、少なくとも何らかの結果を達成するには十分ではありません。 多くの場合、テストが有用になる前であっても、このアクティビティを削減する主な理由は、即時返品の期待です。



しかし、どのような効率について話しているのでしょうか？ 実装の難しさについて歌詞をドロップして、時間テストを節約する具体的な機会がどのように開かれるかを見てみましょう。

どこでもコードを実行する

プロジェクトにテストがない場合、開始する唯一の方法は、アプリケーション全体を解除することです。 約15〜20秒かかりますが、完全な起動に数分かかることがある大規模なプロジェクトの場合はめったにありません。 これは開発者にとって何を意味しますか？ 彼らの作業時間の重要な部分は、これらの短い待機セッションであり、その間、現在のタスクで作業を続けることはできませんが、同時に他の何かに切り替える時間は短すぎます。 多くの人は、修正と修正の間の長い再起動のために1時間で書かれたコードが何時間ものデバッグを必要とするようなプロジェクトに少なくとも一度遭遇しました。 テストでは、アプリケーションの小さな部分の実行に制限することができます。これにより、待ち時間が大幅に短縮され、コードの作業の生産性が向上します。



さらに、任意の場所でコードを実行できるため、より徹底的なデバッグが可能になります。 多くの場合、アプリケーションインターフェースを介して主な肯定的なユースケースをチェックする場合でも、多大な労力と時間が必要です。 テストの存在により、特定の機能の詳細なチェックをはるかに簡単かつ迅速に行うことができます。



別のプラスは、テストされたユニットのサイズを制御する機能です。 テストするロジックの複雑さに応じて、アプリケーション全体のテストの自動化まで、1つのメソッド、クラス、機能を実装するクラスのグループ、サービスなどに制限することができます。 この柔軟性により、低レベルでテストされるため、多くの詳細から高レベルのテストをオフロードできます。

テストの再起動

このプラスはテスト自動化の本質としてよく引用されますが、あまり馴染みのない角度から見てみましょう。 開発者にとってどのような新しい機会が開かれますか？



まず、プロジェクトに参加した新しい開発者は、既存のテストを簡単に実行して、例を使用してアプリケーションのロジックを理解できます。 残念ながら、これの重要性は非常に過小評価されています。 現代の状況では、同じ人が1〜2年以上プロジェクトに取り組むことはめったにありません。 また、チームは数人で構成されているため、2〜3か月ごとに新しい参加者が現れるのは、比較的大規模なプロジェクトの典型的な状況です。 特に難しいプロジェクトは、開発者の世代全体のシフトを受けています！ アプリケーションの任意の部分を簡単に起動し、時々システムの動作を確認できるため、新しいプログラマーがプロジェクトに没頭するのが簡単になります。 さらに、コードロジックのより詳細な調査により、出力で発生するエラーの数と、将来エラーをデバッグする時間を短縮できます。



第二に、アプリケーションが正常に動作していることを簡単に確認できるため、継続的リファクタリングの道が開かれます。 残念ながら、この用語はCIよりもはるかに人気がありません。 これは、すべてのコードを改良することでリファクタリングを実行できることを意味します。 コードベースの劣化を回避し、プロジェクトに長く幸せな生活を保証するのは、悪名高いスカウトルール「到着前よりも駐車場を清潔に保つ」を定期的に遵守することです。

デバッグ

デバッグについては、前の段落で既に説明しましたが、この点は非常に重要であるため、詳しく見る必要があります。 残念ながら、コードの作成とデバッグに費やされた時間の関係を測定する信頼できる方法はありません。これらのプロセスは実際には互いに切り離せないからです。 それでも、プロジェクトで品質テストを使用できると、デバッガーを実行する必要がほとんどなくなるまで、デバッグ時間が大幅に短縮されます。

有効性

上記のすべてにより、コードの初期デバッグの時間を大幅に節約できます。 適切なアプローチを使用すると、これだけですべての追加の開発コストが回収されます。 残りのテストボーナス-コードベースの品質の改善（設計が不十分なコードはテストが困難です）、欠陥の数の削減、いつでもコードの正確性を検証する機能など-はほぼ無料になります。

理論から実践へ

言葉では、それはすべて良いように見えますが、ビジネスに取り掛かりましょう。 前述したように、テスト環境の初期セットアップの作成方法については、十分な資料があります。 したがって、すぐに完成したプロジェクトに進みます。 ソースはこちら。

挑戦する

テンプレートタスクとして、オンラインストアのバックエンドの小さなフラグメントを考えます。 製品を操作するための典型的なAPIを作成します：作成、受信、編集。 クライアントと連携するためのいくつかの方法：「お気に入りの製品」を変更し、注文のボーナスポイントを計算します。

ドメインモデル

例をオーバーロードしないために、フィールドとクラスの最小限のセットに制限します。











顧客には、ユーザー名、お気に入りの製品へのリンク、プレミアム顧客かどうかを示すフラグがあります。



製品（製品）-名前、価格、割引、および現在広告されているかどうかを示すフラグ。

プロジェクト構造

メインプロジェクトコードの構造は次のとおりです。











クラスは階層化されています：

• モデル-プロジェクトのドメインモデル。
• Jpa-Spring Dataに基づいてデータベースを操作するためのリポジトリ。
• サービス-アプリケーションのビジネスロジック。
• コントローラー-APIを実装するコントローラー。

単体テスト構造。











テストクラスは、元のコードと同じパッケージに含まれています。 さらに、テストデータを準備するためのビルダーを含むパッケージが作成されましたが、その詳細については以下を参照してください。



単体テストと統合テストを分離すると便利です。 多くの場合、それらには異なる依存関係があり、快適な開発のために、どちらか一方を実行する機能が必要です。 これはさまざまな方法で実現できます：命名規則、モジュール、パッケージ、sourceSets。 特定の方法の選択はもっぱら好みの問題です。 このプロジェクトでは、統合テストは別のsourceSet-integrationTestにあります。











単体テストと同様に、統合テストを含むクラスは元のコードと同じパッケージに含まれています。 さらに、構成の重複を取り除くのに役立つ基本クラスがあり、必要に応じて便利な汎用メソッドが含まれています。

統合テスト

開始する価値のあるテストにはさまざまなアプローチがあります。 テスト済みのロジックがそれほど複雑でない場合は、すぐに統合ロジックに進むことができます（受け入れロジックとも呼ばれます）。 単体テストとは異なり、アプリケーション全体が正しく動作することを確認します。



建築



まず、どの特定レベルで統合チェックを実行するかを決定する必要があります。 Spring Bootは完全な選択の自由を提供します。コンテキストの一部、コンテキスト全体、さらにはテストからアクセス可能な本格的なサーバーまで上げることができます。 アプリケーションのサイズが大きくなると、この問題はますます複雑になります。 多くの場合、異なるレベルで異なるテストを作成する必要があります。



適切な開始点は、サーバーを起動せずにコントローラーをテストすることです。 比較的小さなアプリケーションでは、デフォルトでテスト間で再利用され、一度だけ初期化されるため、コンテキスト全体を上げることは非常に許容されます。 ProductController



クラスの基本メソッドを検討してください。

 @PostMapping("new") public Product createProduct(@RequestBody Product product) { return productService.createProduct(product); } @GetMapping("{productId}") public Product getProduct(@PathVariable("productId") long productId) { return productService.getProduct(productId); } @PostMapping("{productId}/edit") public void updateProduct(@PathVariable("productId") long productId, @RequestBody Product product) { productService.updateProduct(productId, product); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エラー処理の問題は残されています。 スローされた例外の分析に基づいて外部的に実装されていると仮定します。 メソッドのコードは非常に単純であり、 ProductService



実装はそれほど複雑でProductService



ません。

 @Transactional(readOnly = true) public Product getProduct(Long productId) { return productRepository.findById(productId) .orElseThrow(() -> new DataNotFoundException("Product", productId)); } @Transactional public Product createProduct(Product product) { return productRepository.save(new Product(product)); } @Transactional public Product updateProduct(Long productId, Product product) { Product dbProduct = productRepository.findById(productId) .orElseThrow(() -> new DataNotFoundException("Product", productId)); dbProduct.setPrice(product.getPrice()); dbProduct.setDiscount(product.getDiscount()); dbProduct.setName(product.getName()); dbProduct.setIsAdvertised(product.isAdvertised()); return productRepository.save(dbProduct); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ProductRepository



リポジトリには、独自のメソッドがまったく含まれていません。

 public interface ProductRepository extends JpaRepository<Product, Long> { }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

チェーン全体を複数の統合テストで簡単かつ効率的にチェックできるため、これらのクラスは単体テストを必要としないことをすべて示唆しています。 同じテストを異なるテストに複製すると、デバッグが複雑になります。 コードにエラーが発生した場合、テストは1つではなく、一度に10〜15になります。 これには、さらに分析が必要になります。 重複がない場合、失敗したテストはただちにエラーを示す可能性があります。



構成



便宜上、Spring構成といくつかのフィールドを含む基本クラスBaseControllerIT



を強調表示します。

 @RunWith(SpringRunner.class) @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.NONE) @Transactional public abstract class BaseControllerIT { @Autowired protected ProductRepository productRepository; @Autowired protected CustomerRepository customerRepository; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リポジトリは、テストクラスが乱雑にならないように基本クラスに移動されます。 それらの役割は、補助的なものです。データの準備と、コントローラーの動作後のデータベースのステータスの確認です。 アプリケーションのサイズが大きくなると、これはもはや便利ではないかもしれませんが、最初は非常に適しています。



Springの主な構成は、次の行で定義されます。



@SpringBootTest



アプリケーションのコンテキストを設定するために使用されます。 WebEnvironment.NONE



は、Webコンテキストを上げる必要がないことを意味します。



@Transactional



Transactional-トランザクション内のすべてのクラステストを自動ロールバックでラップして、データベースの状態を保存します。



試験構造



ProductController



クラスのテストの最小限のセットであるProductController



ましょう。

 @Test public void createProduct_productSaved() { Product product = product("productName").price("1.01").discount("0.1").advertised(true).build(); Product createdProduct = productController.createProduct(product); Product dbProduct = productRepository.getOne(createdProduct.getId()); assertEquals("productName", dbProduct.getName()); assertEquals(number("1.01"), dbProduct.getPrice()); assertEquals(number("0.1"), dbProduct.getDiscount()); assertEquals(true, dbProduct.isAdvertised()); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テストコードは非常にシンプルで、一目で理解できるものでなければなりません。 そうでない場合、記事の最初のセクションで説明したテストの利点のほとんどが失われます。 テスト本体を、視覚的に互いに分離できる3つの部分に分割することをお勧めします。データの準備、テストメソッドの呼び出し、結果の検証です。 同時に、テストコードが画面全体に収まることが非常に望ましいです。



個人的には、データ準備セクションのテスト値が後のチェックで使用されると、より明白に思えます。 または、次のようにオブジェクトを明示的に比較することもできます。

 assertEquals(product, dbProduct);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

製品情報を更新する別のテスト（ updateProduct



）では、データの作成がもう少し複雑になり、テストの3つの部分の視覚的整合性を維持するために、2つの行フィードが連続して分離されていることが明らかです：

 @Test public void updateProduct_productUpdated() { Product product = product("productName").build(); productRepository.save(product); Product updatedProduct = product("updatedName").price("1.1").discount("0.5").advertised(true).build(); updatedProduct.setId(product.getId()); productController.updateProduct(product.getId(), updatedProduct); Product dbProduct = productRepository.getOne(product.getId()); assertEquals("updatedName", dbProduct.getName()); assertEquals(number("1.1"), dbProduct.getPrice()); assertEquals(number("0.5"), dbProduct.getDiscount()); assertEquals(true, dbProduct.isAdvertised()); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

生地の3つの部分はそれぞれ単純化できます。 データの準備には、テストビルダーが優れています。これには、テストから使用するのに便利なオブジェクトを作成するためのロジックが含まれています。 あまりにも複雑なメソッド呼び出しをテストクラス内の補助メソッドにして、このクラスに関係のないパラメーターの一部を非表示にすることができます。 複雑なチェックを簡素化するために、補助関数を作成するか、独自のマッチャーを実装することもできます。 これらすべての単純化の主なことは、テストの可視性を失うことではありません。すべてをメインメソッドで一目でわかるようにし、さらに深くする必要はありません。



テストビルダー



テストビルダーには特別な注意が必要です。 オブジェクト作成のロジックをカプセル化すると、テストのメンテナンスが簡単になります。 特に、このテストに関係のないモデルフィールドの入力は、ビルダー内で非表示にできます。 これを行うには、直接作成する必要はありませんが、欠落しているフィールドにデフォルト値を入力する静的メソッドを使用します。 たとえば、新しい必須フィールドがモデルに表示される場合、このメソッドに簡単に追加できます。 ProductBuilder



、次のようになります。

 public static ProductBuilder product(String name) { return new ProductBuilder() .name(name) .advertised(false) .price("0.00"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テスト名



このテストで具体的に何がテストされるかを理解することが不可欠です。 明確にするために、タイトルでこの質問に答えるのが最善です。 getProduct



メソッドのサンプルテストを使用して、使用される命名規則を検討してください。

 @Test public void getProduct_oneProductInDb_productReturned() { Product product = product("productName").build(); productRepository.save(product); Product result = productController.getProduct(product.getId()); assertEquals("productName", result.getName()); } @Test public void getProduct_twoProductsInDb_correctProductReturned() { Product product1 = product("product1").build(); Product product2 = product("product2").build(); productRepository.save(product1); productRepository.save(product2); Product result = productController.getProduct(product1.getId()); assertEquals("product1", result.getName()); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一般的な場合、テストメソッドの見出しは、下線で区切られた3つの部分で構成されます。テストするメソッドの名前、スクリプト、および期待される結果です。 ただし、誰も常識を取り消しませんでした。このコンテキストで必要でない場合は、名前の一部を省略することは正当化される場合があります（たとえば、製品を作成するための単一テストのスクリプト）。 この命名の目的は、コードを学習せずに各テストの本質を理解できるようにすることです。 これにより、テスト結果のウィンドウができる限り明確になり、通常はテストの作業が開始されます。











結論



以上です。 ProductController



クラスのメソッドをテストするには、初めて4つのテストの最小限のセットで十分です。 バグを検出した場合、いつでも欠落しているテストを追加できます。 同時に、テストの最小数は、それらをサポートする時間と労力を大幅に削減します。 最初のテストは通常​​最高の品質ではなく、多くの予期しない問題を引き起こすため、これはテストの実装において重要です。 同時に、このようなテストスイートは、記事の最初の部分で説明したボーナスを受け取るのに十分です。



このようなテストはアプリケーションのWebレイヤーをチェックしませんが、多くの場合これは必須ではありません。 必要に応じて、ベース（ @WebMvcTest



、 MockMvc



、 @MockBean



）の代わりにスタブを使用してWebレイヤーの個別のテストを作成するか、本格的なサーバーを使用できます。 テストではサーバーのトランザクションを制御できないため、後者はデバッグを複雑にし、トランザクションの処理を複雑にする可能性があります。 このような統合テストの例は、 CustomerControllerServerIT



クラスにあります。

単体テスト

単体テストには、統合テストよりもいくつかの利点があります。

• 起動には数ミリ秒かかります。
• テスト済みユニットのサイズが小さい。
• メソッドを直接呼び出すと、データの準備が大幅に簡素化されるため、多数のオプションの検証を簡単に実装できます。

それにもかかわらず、単体テストはその性質上、アプリケーション全体の操作性を保証することはできず、統合テストの作成を避けることはできません。 テスト対象のユニットのロジックが単純な場合、ユニットテストと統合テストを複製してもメリットはありませんが、サポートするコードを追加するだけです。



この例で単体テストに値する唯一のクラスはBonusPointCalculator



です。 その際立った機能は、ビジネスロジックの多数のブランチです。 たとえば、バイヤーが製品のコストの10％のボーナスを受け取り、次のリストから2つ以下の乗数が乗算されると仮定します。

• 製品の価格は10,000（×4）以上です。
• 製品は広告キャンペーンに参加しています（×3）。
• 製品は、顧客の「お気に入り」製品です（×5）。
• クライアントにはプレミアムステータス（×2）があります。
• クライアントにプレミアムステータスがあり、「お気に入り」の製品を購入する場合、示されている2つの乗数の代わりに1つ（×8）が使用されます。

もちろん、実際には、これらのボーナスを計算するための柔軟な汎用メカニズムを設計する価値がありますが、例を単純化するために、固定された実装に限定しています。 乗数の計算コードは次のようになります。

 private List<BigDecimal> calculateMultipliers(Customer customer, Product product) { List<BigDecimal> multipliers = new ArrayList<>(); if (customer.getFavProduct() != null && customer.getFavProduct().equals(product)) { if (customer.isPremium()) { multipliers.add(PREMIUM_FAVORITE_MULTIPLIER); } else { multipliers.add(FAVORITE_MULTIPLIER); } } else if (customer.isPremium()) { multipliers.add(PREMIUM_MULTIPLIER); } if (product.isAdvertised()) { multipliers.add(ADVERTISED_MULTIPLIER); } if (product.getPrice().compareTo(EXPENSIVE_THRESHOLD) >= 0) { multipliers.add(EXPENSIVE_MULTIPLIER); } return multipliers; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

多数のオプションがあるため、ここでは2つまたは3つの統合テストが制限されません。 単体テストの最小限のセットは、このような機能のデバッグに最適です。











対応するテストスイートはBonusPointCalculatorTest



クラスにあります。 それらのいくつかを次に示します。

 @Test public void calculate_oneProduct() { Product product = product("product").price("1.00").build(); Customer customer = customer("customer").build(); Map<Product, Long> quantities = mapOf(product, 1L); BigDecimal bonus = bonusPointCalculator.calculate(customer, list(product), quantities::get); BigDecimal expectedBonus = bonusPoints("0.10").build(); assertEquals(expectedBonus, bonus); } @Test public void calculate_favProduct() { Product product = product("product").price("1.00").build(); Customer customer = customer("customer").favProduct(product).build(); Map<Product, Long> quantities = mapOf(product, 1L); BigDecimal bonus = bonusPointCalculator.calculate(customer, list(product), quantities::get); BigDecimal expectedBonus = bonusPoints("0.10").addMultiplier(FAVORITE_MULTIPLIER).build(); assertEquals(expectedBonus, bonus); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テストでは、パブリッククラスAPI- calculate



メソッドを具体的に参照していることに注意してください。 実装ではなくクラスコントラクトをテストすると、機能以外の変更やリファクタリングによるテストの故障を回避できます。



最後に、単体テストで内部ロジックをテストしたときに、これらすべての詳細を統合する必要がなくなりました。 この場合、1つの多かれ少なかれ代表的なテストで十分です。たとえば、次のとおりです。

 @Test public void calculateBonusPoints_twoProductTypes_correctValueCalculated() { Product product1 = product("product1").price("1.01").build(); Product product2 = product("product2").price("10.00").build(); productRepository.save(product1); productRepository.save(product2); Customer customer = customer("customer").build(); customerRepository.save(customer); Map<Long, Long> quantities = mapOf(product1.getId(), 1L, product2.getId(), 2L); BigDecimal bonus = customerController.calculateBonusPoints( new CalculateBonusPointsRequest("customer", quantities) ); BigDecimal bonusPointsProduct1 = bonusPoints("0.10").build(); BigDecimal bonusPointsProduct2 = bonusPoints("1.00").quantity(2).build(); BigDecimal expectedBonus = bonusPointsProduct1.add(bonusPointsProduct2); assertEquals(expectedBonus, bonus); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

統合テストの場合と同様に、使用される単体テストのセットは非常に小さく、アプリケーションの完全性を保証するものではありません。 それでも、その存在はコードの信頼性を大幅に高め、デバッグを容易にし、記事の最初の部分にリストされている他のボーナスを与えます。

実装の推奨事項

前のセクションで、少なくとも1人の開発者がプロ​​ジェクトでテストの使用を開始するように説得するのに十分であることを願っています。 この章では、深刻な問題を回避し、初期実装コストを削減するのに役立つ主な推奨事項を簡単にリストします。



新しいアプリケーションでテストの実装を開始してみてください。 大規模なレガシープロジェクトで最初のテストを書くことは、新しく作成したプロジェクトよりもはるかに難しく、より多くのスキルを必要とします。 したがって、可能であれば、小さな新しいアプリケーションから開始することをお勧めします。 新しい本格的なアプリケーションが期待されていない場合は、内部で使用するための有用なユーティリティの開発を試みることができます。 主なことは、タスクが多かれ少なかれ現実的であるべきだということです-発明された例は本格的な経験を与えません。



定期的なテスト実行を設定します。 テストが定期的に実行されない場合、メイン機能の実行を停止するだけでなく、コードの正確性を確認するだけでなく、すぐに古くなってしまいます。 したがって、リポジトリでコードが更新されるたびにテストを自動的に起動するように、少なくとも最小限のCIパイプラインを構成することが非常に重要です。



カバーを追いかけないでください。 他の技術の場合のように、最初は最高品質のテストは取得されません。 関連する文献（記事の最後にあるリンク）または有能なメンターがここで役立ちますが、これは自己充填コーンの必要性をキャンセルしません。 この点でのテストは、コードの残りの部分と似ています。プロジェクトにどのように影響するかを理解するためには、しばらくテストを行ってからでなければできません。 したがって、被害を最小限に抑えるために、最初は100％のカバレッジのような数字や美しい数字を追いかけない方が良いでしょう。 代わりに、独自のアプリケーション機能の主な肯定的なシナリオに限定する必要があります。



単体テストに夢中にならないでください。 「量対品質」というテーマを続けると、正直な単体テストは初めて実行されるべきではないことに注意する必要があります。これは、アプリケーションの過剰な仕様に容易につながる可能性があるからです。 次に、これは、後続のリファクタリングおよびアプリケーションの改善中に重大な阻害要因になります。 単体テストは、特定のクラスまたはクラスのグループに複雑なロジックがある場合にのみ使用する必要があります。これは、統合レベルで確認するには不便です。



スタブクラスとアプリケーションメソッドに夢中にならないでください。 スタブ（スタブ、モック）は、バランスの取れたアプローチとバランスの維持を必要とするもう1つのツールです。 一方では、ユニットを完全に分離することで、システムの残りの部分について考えることなく、テスト済みのロジックに集中することができます。 一方、これには追加の開発時間が必要であり、単体テストと同様に、動作の過剰な指定につながる可能性があります。



外部システムから統合テストを解きます。 統合テストでよくある間違いは、実際のデータベース、メッセージキュー、およびアプリケーション外部の他のシステムの使用です。 もちろん、実際の環境でテストを実行する機能は、デバッグと開発に役立ちます。 このような少量のテストは、特にインタラクティブに実行する場合に意味があります。 ただし、それらの広範な使用は多くの問題につながります。

1. テストを実行するには、外部環境を構成する必要があります。 たとえば、アプリケーションがアセンブルされる各マシンにデータベースをインストールします。 これにより、新しい開発者がプロ​​ジェクトに参加してCIを構成することが難しくなります。
2. 外部システムの状態は、テストを実行する前にマシンによって異なる場合があります。 たとえば、データベースには、テストで予期されていないデータでアプリケーションが必要とするテーブルが既に含まれている場合があります。 これにより、テストで予測不可能な障害が発生し、それらの除去にはかなりの時間がかかります。
3. 複数のプロジェクトで並行作業が進行している場合、一部のプロジェクトが他のプロジェクトに非自明な影響を与える可能性があります。 たとえば、プロジェクトの1つに対して行われた特定のデータベース設定は、別のプロジェクトの機能が正しく機能するのに役立ちますが、別のマシンのクリーンデータベースで起動すると壊れます。
4. テストは長時間実行されます。フル実行には数十分かかる場合があります。 これは、開発者がテストをローカルで実行するのを停止し、リモートリポジトリに変更を送信した後にのみ結果を確認するという事実につながります。 この動作は、この記事の最初の部分で説明したテストの利点のほとんどを無効にします。

統合テスト間のコンテキストをクリアします。 多くの場合、統合テストを高速化するには、それらの間で同じコンテキストを再利用する必要があります。 Springの公式ドキュメントでもこのような推奨事項があります。 同時に、相互のテストの影響を避ける必要があります。 それらは任意の順序で起動されるため、このような接続が存在すると、ランダムで再現不可能なエラーが発生する可能性があります。 これを防ぐために、テストではコンテキストの変更を残さないでください。 たとえば、データベースを使用する場合、通常は分離のために、テストでコミットされたすべてのトランザクションをロールバックするだけで十分です。 コンテキストの変更が避けられない場合は、 @DirtiesContext



アノテーションを使用してそのレクリエーションを設定できます。



テストが妥当な時間内に実行されることを確認してください。テストが実際の外部システムに依存していなくても、実行時間は簡単に手に負えなくなる可能性があります。これを防ぐには、このインジケータを常に監視し、必要に応じて対策を講じる必要があります。実行できる最小の方法は、低速テストを個別のグループに分けて、それらに関係のないタスクの作業を妨げないようにすることです。



テストをできるだけ明確で読みやすいものにしてください。例ですでに示したように、テストは理解する必要がないように作成する必要があります。テストの学習に費やした時間は、コードの学習に費やすことができます。



TDD（テスト駆動開発）でハングアップしないでください。TDDはかなり一般的な方法ですが、特に実装の初期段階では、TDDは必須ではありません。一般に、適切なテストを作成する能力は、テストを作成する時点とは関係ありません。これは時間を節約するための主要な方法の1つであるため、本当に重要なのは、テストで既にコードの初期デバッグを行うことです。

最初のテストは書かれていますが、次は何ですか？

次に、プロジェクトのテストの寿命を注意深く監視し、次のような質問を定期的に自問する必要があります。

1. どのテストがリファクタリングと改善を妨げますか（一定の修正が必要です）？このようなテストは、書き直すか、プロジェクトから完全に削除して、より高いテストに置き換える必要があります。
2. 異なる環境（同僚のコンピューター、CIサーバー）で実行している場合、複数の起動または並列起動中に頻繁に、予測できないテストが行​​われますか？また、処理が必要です。
3. どのエラーがテストに合格しますか？このようなバグごとに、新しいテストを追加し、同様の機能のテストを作成するときにそれらを将来的に考慮しておくことをお勧めします。
4. どのテストが長すぎますか？それらを書き直さなければなりません。これが不可能な場合は、ローカルで実行される可能性を維持するために、それらをより高速なものから分離します。

さらに、この記事の冒頭で説明したテストの利点に注意する価値があります。あなたがそれらを受け取らなかった場合、何かが間違っています。定期的な回顧は、使用するテストの品質と有効性を一貫して向上させる最も安価な方法です。

おわりに

最初は、テストの数を追いかけるのではなく、テストの品質に焦点を当てる方が良いです。膨大な数の不適切な単体テストは、簡単にアンカーになり、プロジェクトを底辺に引き込む可能性があります。さらに、単体テストの存在は、統合テストを記述する必要性を免れません。したがって、最初の最も効果的な戦略は、統合テストで主なポジティブシナリオをカバーすることから始め、これで十分でない場合は、ユニットテストでローカルチェックを追加することです。時間が経つにつれてフィードバックが蓄積され、これにより、ミスを修正し、さまざまな自動テスト方法の効果的な使用についてより明確なアイデアを得ることができます。



読んでいる人たちの中に、私の魂の細い弦が私の書癖の影響を受ける人たちがいることを願っています。そして、さらに効果的で効果的なテストを含むいくつかのプロジェクトが世界に現れるでしょう！



GitHubプロジェクトのソース