👩‍🔬 🕗 ⚓️ パフペストリーの原則 🌸 🎰 🧀

否定から有罪判決への道のすべての臆することなく捧げられます...

開発者の間では、プログラマーがコードをテストでカバーしないと、なぜそれらが必要なのか、そしてそれらをどのように準備するのかを理解できないという公正な意見があります。それが何であるかをすでに理解しているとき、これに異議を唱えるのは難しいです。しかし、この貴重な理解をどのように達成できるでしょうか。

それは意図されていません...

グローバルネットワーク上の膨大な数の有用な情報の中で、最も明白なことが明確に説明されていないことがよくあります。ある種の常連の申請者は、「ユニットテストとは何か」という緊急の質問に対処することを決定し、トレースペーパーのように記事から記事へとコピーされるそのような例の多くに出くわします。

「数値の合計を計算するメソッドがあります」

publicInteger sum（Integer a、Integer b）{

return a + b

}

「このメソッドのテストを記述できます」

テスト

public void testGoodOne（）{

assertThat（sum（2,2）、is（4））;

}

これは冗談ではありません。これはユニットテスト技術に関する典型的な記事の簡略化された例です。最初と最後に利点と必要性についての一般的なフレーズがあり、途中で...

これを見て、信仰のために2回読み直すと、申請者は次のように叫びます。？.. "結局のところ、彼のコードには、引数を通じて必要なすべてを受け取り、それらに明確な結果を与えるメソッドは事実上ありません。これらは典型的な実用的な方法であり、ほとんど変わりません。しかし、複雑なプロシージャ、挿入された依存関係、および値を返さないメソッドについてはどうでしょうか。そこでは、このアプローチは「まったく」という言葉からは適用できません。

この段階で頑固な申請者が手を振らずにさらに飛び込んだ場合、彼はすぐにMOCが依存関係に使用されていることを発見します。そのメソッドには、条件付きの動作が定義されています。実際にはスタブです。ここでは、近くにすべてを説明する準備ができて忍耐強い中高年がいなければ、申請者は完全に頭を悩ませることができます...そうでなければ、テストされた方法のほとんどが何らかのモックフィクションであることが判明するため、真実の申請者は「ユニットテストとは何か」の意味を完全に失います、この場合に何がテストされているかは明確ではありません。さらに、これを大規模な多層アプリケーション用に編成する方法と、これが必要な理由は明確ではありません。したがって、せいぜい、質問はより良い時期まで延期され、最悪の場合、それはひどいものの箱の中に隠れます。

最も厄介なのは、テストカバレッジテクノロジーが基本的にシンプルで誰もがアクセスできることです。その利点は非常に明白であるため、知識のある人にとっては言い訳が素朴に見えます。しかし、それを理解するために、初心者はスイッチのフリップのようないくつかの非常に小さな、基本的な本質を欠いています。

主な使命

まず、ユニットテストのキー機能（ミッション）とキーゲインを一言で表すことを提案します。ここにはさまざまな美しいオプションがありますが、これを検討することを提案し

ます。ユニットテスト の 重要な機能は、システムの予想される動作を記録することです。

これは、ユニットテストの

主な利点は、アプリケーションのすべての機能を数秒で「実行」できることです。

インタビューのためにこれを覚えておくことをお勧めします。少し説明します。すべての機能は、使用規則と結果を意味します。これらの要件は、システム分析を通じてビジネスからもたらされ、コードで実装されます。しかし、コードは絶えず進化しており、新しい要件と改善が行われ、完成した機能の何かがいつの間にか予期せず変更される可能性があります。これは、ユニットテストがガードを立てる場所であり、システムが機能するための承認されたルールを修正します。テストはビジネスにとって重要なシナリオを記録し、次の改訂後にテストが失敗した場合、何かが欠けています。開発者またはアナリストのいずれかが間違っているか、新しい要件が既存の要件と矛盾しているため、明確にする必要があります。最も重要なことは、「驚き」がすり抜けなかったことです。

シンプルな標準ユニットテストにより、予期しない、おそらく望ましくないシステム動作を早期に検出することができました。その間、システムは成長し、拡張し、その詳細を見逃す可能性も高まり、ユニットテストスクリプトだけがすべてを記憶し、時間内の知覚できない逸脱を防ぐことができます。それは非常に便利で信頼性が高く、主な便利さはスピードです。アプリケーションを実行して、何百ものフィールド、フォーム、またはボタンをさまよっている必要はありません。テストを実行して、完全な準備またはバグを数秒で取得する必要があります。

したがって、覚えておきましょう。ユニットテストスクリプトの形式で予想される動作を修正し、アプリケーションを起動せずに即座に「実行」します。これは、ユニットテストで達成できる絶対値です。

しかし、くそー、どうやって？

楽しい部分に移りましょう。現代のアプリケーションは積極的にモノリシック性を取り除きつつあります。マイクロサービス、モジュール、「レイヤー」-作業コードを整理する基本原則。これにより、独立性、再利用の容易さ、システムへの交換と転送などを実現できます。このトピックでは、階層化と依存関係の注入が重要です。

典型的なWebアプリケーションのレイヤー（コントローラー、サービス、リポジトリなど）について考えてみます。さらに、ユーティリティ、ファサード、モデル、およびDTOレイヤーが使用されます。最後の2つには、機能を含めるべきではありません。アクセサー（ゲッター/セッター）以外のメソッドなので、テストでカバーする必要はありません。残りのレイヤーをカバレッジのターゲットと見なします。

この比較がどれほどおいしいかを示唆していても、依存関係のように、これらのレイヤーが互いに埋め込まれているため、アプリケーションをパフケーキと比較することはできません。

コントローラは、結果を要求するサービスを実装します
サービスはそれ自体にリポジトリ（DAO）を挿入し、ユーティリティコンポーネントを挿入できます
ファサードは、それぞれ多くのサービスまたはコンポーネントの作業を組み合わせるように設計されており、それらを実装します

アプリケーション全体でこれらすべてをテストする主なアイデア：他のレイヤーとは独立して各レイヤーをカバーします。独立性およびその他の反モノリシック機能への参照。それら。テストされたサービスにリポジトリが埋め込まれている場合、この「ゲスト」はサービスのテストの一部としてモックされますが、リポジトリテストの一部としてすでに正直に個人的にテストされています。したがって、テストは各レイヤーの要素ごとに作成され、誰もが忘れられることはありません。すべてがビジネスにあります。

パフペストリーの原則

例、Java Spring Bootの単純なアプリケーションに移りましょう。コードは基本的なものになるため、本質は理解しやすく、他の最新の言語/フレームワークにも同様に適用できます。アプリケーションには簡単なタスクがあります-数値に3を掛けます。トリプルですが、同時に、依存関係の注入と頭からつま先までのレイヤードカバレッジを備えたマルチレイヤーアプリケーションを作成します。

この構造には、コントローラー、サービス、リポジトリの3つのレイヤーのパッケージが含まれています。テストの構造は似ています。

アプリケーションは次のように機能します。

フロントエンドから、3倍にする必要のある番号の識別子を使用してGET要求がコントローラーに送信されます。
コントローラは、サービスの依存関係から結果を要求します
サービスは依存関係（リポジトリ）からデータを要求し、乗算して結果をコントローラに返します
コントローラは結果を補完し、フロントエンドに戻ります

コントローラから始めましょう：

@RestController
@RequiredArgsConstructor
public class SomeController {
   private final SomeService someService; // dependency injection

   static final String RESP_PREFIX = ": ";

   static final String PATH_GET_TRIPLE = "/triple/{numberId}";

   @GetMapping(path = PATH_GET_TRIPLE) // mapping method to GET with url=path
   public ResponseEntity<String> triple(@PathVariable(name = "numberId") int numberId) {
       int res = someService.tripleMethod(numberId);   // dependency call
       String resp = RESP_PREFIX + res;                // own logic
       return ResponseEntity.ok().body(resp);
   }
}

典型的なレストコントローラーには、依存関係の注入someServiceがあります。トリプルメソッドは、URL "/ triple / {numberId}"へのリクエストをGETするように構成されています。ここで、番号識別子はパス変数で渡されます。メソッド自体は、2つの主要なコンポーネントに分けることができます。

依存関係へのアクセス-外部からのデータの要求、または結果のないプロシージャの呼び出し
独自のロジック-既存のデータの操作

サービスについて考えてみましょう。

@Service
@RequiredArgsConstructor
public class SomeService {
   private final SomeRepository someRepository; // dependency injection

   public int tripleMethod(int numberId) {
       Integer fromDB = someRepository.findOne(numberId);  // dependency call
       int res = fromDB * 3;                               // own logic
       return res;
   }
}

同様の状況があります。someRepository依存関係を挿入し、メソッドは依存関係とそれ自体のロジックにアクセスすることで構成されます。

最後に、リポジトリは、簡単にするために、データベースなしで実行されます。

@Repository
public class SomeRepository {
   public Integer findOne(Integer id){
       return id;
   }
}

findOne条件付きメソッドは、おそらくデータベースで識別子によって値を検索しますが、単に同じ整数を返します。これは、この例の本質には影響しません。

アプリケーションを実行すると、構成されたURLによって次のように表示されます

。レイヤード！生産中...

そうそう、テスト...

本質について少し。テストを書くことも創造的なプロセスです！したがって、「私はテスターではなく開発者です」という言い訳はまったく不適切です。優れた機能性と同様に、優れたテストには創意工夫と美しさが必要です。しかし、まず第一に、テストの基本的な構造を決定する必要があります。

テストクラスには、ターゲットクラスのメソッドをテストするメソッドが含まれています。各テストメソッドに含める必要のある最小値は、条件付きで次のように言えば、ターゲットクラスの対応するメソッドの呼び出しです。

@Test
    void someMethod_test() {
        // prepare...

        int res = someService.someMethod(); 
        
        // check...
    }

この課題は、準備とレビューに囲まれている可能性があります。入力引数を含むデータの準備とモックの動作の説明。結果の検証は通常、期待値との比較です。期待される動作をキャプチャすることを覚えていますか？全体として、テストは状況をシミュレートし、期待どおりに合格し、期待された結果を返したことを記録するシナリオです。

例としてコントローラーを使用して、テストを作成するための基本的なアルゴリズムを詳細に説明してみましょう。まず、ターゲットコントローラーメソッドはint numberIdパラメーターを取ります。それをスクリプトに追加しましょう：

int numberId = 42; // input path variable

同じnumberIdが、サービスメソッドへの入力に転送中に送信されます。次に、サービスモックを提供します。

@MockBean
private SomeService someService;

コントローラ自体のメソッドコードは、サービスから受け取った結果を処理します。この結果と、それを返す呼び出しをシミュレートします。


int serviceRes = numberId*3; // result from mock someService
// prepare someService.tripleMethod behavior
when(someService.tripleMethod(eq(numberId))).thenReturn(serviceRes);

このエントリは、「someService.tripleMethodがnumberIdに等しい引数で呼び出された場合、serviceResの値を返す」ことを意味します。

さらに、このエントリは、このサービスメソッドを呼び出す必要があるという事実をキャプチャします。これは重要なポイントです。結果のないプロシージャの呼び出しを修正する必要がある場合は、通常は別の表記法が使用されます-「...の場合は何もしない」：


Mockito.doNothing().when(someService).someMethod(eq(someParam));

繰り返しになりますが、これはsomeServiceの作業の単なる模倣であり、someServiceの動作を詳細に修正した正直なテストが個別に実装されます。さらに、ここでは、次のように記述した場合、値が3倍になることも重要ではありません。


int serviceRes = numberId*5;

これは現在のスクリプトを壊すことはありません。ここでキャプチャされるのはsomeServiceの動作ではなく、someServiceの結果を当然のことと見なすコントローラの動作です。ターゲットクラスは挿入された依存関係の動作を担当できませんが、それを信頼する必要があるため、これは完全に論理的です。

したがって、スクリプトでモックの動作を定義しました。したがって、テストを実行するときに、ターゲットメソッドの呼び出し内でモックに到達すると、要求されたもの（serviceRes）が返され、コントローラー自体のコードがこの値で機能します。

次に、スクリプト内のターゲットメソッドを呼び出します。コントローラメソッドには特殊性があります。コードでは明示的に呼び出されませんが、HTTP GETメソッドとURLを介してバインドされるため、テストでは特別なテストクライアントを介して呼び出されます。Springでは、これはMockMvcです。他のフレームワークでは、SymfonyのWebTestCase.createClientなどの類似物があります。したがって、さらに、GETとURLによるマッピングを介してコントローラーメソッドを実行するのは簡単です。


       //// mockMvc.perform
       MockHttpServletRequestBuilder requestConfig = MockMvcRequestBuilders.get(SomeController.PATH_GET_TRIPLE, numberId);

       MvcResult mvcResult = mockMvc.perform(requestConfig)
           .andExpect(status().isOk())
           //.andDo(MockMvcResultHandlers.print())
           .andReturn()
       ;//// mockMvc.perform

また、そのようなマッピングが存在することも確認されます。呼び出しが成功した場合、結果を確認して修正することになります。たとえば、モックメソッドが呼び出された回数を修正できます。


// check of calling
Mockito.verify(someService, Mockito.atLeastOnce()).tripleMethod(eq(numberId));

私たちの場合、これは冗長です。whenの唯一の呼び出しはすでに修正されていますが、この方法が適切な場合もあります。

そして今、主なこと-コントローラー自体のコードの動作をチェックします：


// check of result
assertEquals(SomeController.RESP_PREFIX+serviceRes, mvcResult.getResponse().getContentAsString());

ここで、メソッド自体の原因を修正しました。someServiceから受信した結果は、コントローラープレフィックスと連結され、応答の本文に入るのはこの行です。ちなみに、コメントを外すとボディの内容を自分の目で見ることができます


//.andDo(MockMvcResultHandlers.print())

ただし、通常、このコンソールへの印刷は、デバッグの補助としてのみ使用されます。

したがって、コントローラーテストクラスにテストメソッドがあります。


@WebMvcTest(SomeController.class)
class SomeControllerTest {
   @MockBean
   private SomeService someService;

   @Autowired
   private MockMvc mockMvc;

   @Test
   void triple() throws Exception {
       int numberId = 42; // input path variable
       int serviceRes = numberId*3; // result from mock someService
       // prepare someService.tripleMethod behavior
       when(someService.tripleMethod(eq(numberId))).thenReturn(serviceRes);

       //// mockMvc.perform
       MockHttpServletRequestBuilder requestConfig = MockMvcRequestBuilders.get(SomeController.PATH_GET_TRIPLE, numberId);

       MvcResult mvcResult = mockMvc.perform(requestConfig)
           .andExpect(status().isOk())
           //.andDo(MockMvcResultHandlers.print())
           .andReturn()
       ;//// mockMvc.perform

       // check of calling
       Mockito.verify(someService, Mockito.atLeastOnce()).tripleMethod(eq(numberId));
       // check of result
       assertEquals(SomeController.RESP_PREFIX+serviceRes, mvcResult.getResponse().getContentAsString());
   }
}

次に、someService.tripleMethodメソッドを正直にテストします。同様に、依存関係の呼び出しと独自のコードがあります。任意の入力引数を準備し、someRepository依存関係の動作をシミュレートします。


int numberId = 42;
when(someRepository.findOne(eq(numberId))).then(AdditionalAnswers.returnsFirstArg());

翻訳：「someRepository.findOneがnumberIdに等しい引数で呼び出された場合、同じ引数を返します。」同様の状況-ここでは依存の論理をチェックしませんが、その言葉を受け入れます。このメソッド内の依存関係への呼び出しのみをキャプチャします。ここでの原則は、サービス自体のロジック、その責任範囲です：


assertEquals(numberId*3, res);

リポジトリから受け取った値は、メソッド自体のロジックによって3倍にする必要があることを修正しました。現在、このテストはこの要件を保護しています。


@ExtendWith(MockitoExtension.class)
class SomeServiceTest {
   @Mock
   private SomeRepository someRepository; // ,  

   @InjectMocks
   private SomeService someService; //   ,  

   @Test
   void tripleMethod() {
       int numberId = 42;
       when(someRepository.findOne(eq(numberId))).then(AdditionalAnswers.returnsFirstArg());

       int res = someService.tripleMethod(numberId);

       assertEquals(numberId*3, res);
   }
}

私たちのリポジトリは条件付きでおもちゃであるため、テストは適切であることが判明しました。


class SomeRepositoryTest {
   // no dependency injection
   private final SomeRepository someRepository = new SomeRepository();

   @Test
   void findOne() {
       int id = 777;
       Integer fromDB = someRepository.findOne(id);
       assertEquals(id, fromDB);
   }
}

ただし、ここでも、準備、呼び出し、検証というスケルトン全体が整っています。したがって、someRepository.findOneの正しい動作が修正されます。

実際のリポジトリでは、メモリまたはテストコンテナでデータベースを起動し、構造とデータを移行し、場合によってはテストレコードを挿入してテストする必要があります。これは多くの場合、最長のテストレイヤーですが、それほど重要ではありません。正常な移行、モデルの保存、正しい選択などが記録されます。データベーステストの構成はこの記事の範囲を超えていますが、マニュアルで詳細に説明されています。リポジトリには依存関係の挿入はなく、必要ありません。そのタスクはデータベースを操作することです。私たちの場合は、レコードをデータベースに事前に保存し、その後IDで検索するテストになります。

このようにして、機能チェーン全体を完全にカバーすることができました。各テストは、独自のコードを実行し、すべての依存関係への呼び出しをキャプチャします。アプリケーションのテストでは、完全なコンテキストレイズを使用してアプリケーションを実行する必要はありません。これは、困難で時間がかかります。迅速で簡単なユニットテストで機能を維持することで、快適で信頼性の高い作業環境が実現します。

さらに、テストによってコードの品質が向上します。レイヤーでの独立したテストの一環として、コードをどのように編成するかを再考する必要があることがよくあります。たとえば、メソッドは最初にサービスで作成され、小さくはなく、独自のコードとモックの両方が含まれています。たとえば、メソッドを分割する意味がなく、完全にテストでカバーされています。すべての準備とチェックが定義されています。次に、誰かが最初のメソッドを呼び出す2番目のメソッドをサービスに追加することにしました。かつては一般的な状況のようですが、テストの対象範囲になると、何かが足りません... 2番目の方法では、2番目のシナリオを説明し、最初の準備シナリオを複製する必要がありますか？結局のところ、テストされたクラス自体の最初のメソッドをロックすることはできません。

おそらく、この場合、コードの別の編成について考えるのが適切です。2つの反対のアプローチがあります：

最初のメソッドを、サービスへの依存関係として挿入されるユーティリティコンポーネントに移動します。
2番目の方法を、組み込みサービスまたは複数のサービスのさまざまな方法を組み合わせたサービスファサードに移動します。

これらのオプションは両方とも「レイヤー」の原則にうまく適合し、依存関係のモックで便利にテストされます。美しさは、各レイヤーが独自の作業を担当し、それらが一緒になって、システム全体の無敵性のための強固なフレームワークを作成することです。

軌道に乗って ...

インタビューの質問：開発者はチケット内で何回テストを実行する必要がありますか？好きなだけ、ただし少なくとも2回：

仕事を始める前に、すべてが問題ないことを確認し、後であなたではなく、すでに壊れているものを見つけないようにします
仕事の終わりに

では、なぜテストを書くのでしょうか？次に、大規模で複雑なアプリケーションのすべてを覚えて予測する価値がないため、これは自動化に任せる必要があります。自動テストを所有していない開発者は、大規模なプロジェクトに参加する準備ができていません。インタビュー対象者はすぐにこれを明らかにします。

したがって、高給の資格を得たい場合は、これらのスキルを開発することをお勧めします。このエキサイティングな練習は、基本的なことから始めることができます。つまり、お気に入りのフレームワークのフレームワーク内で、テストする方法を学びます。

依存関係が埋め込まれたコンポーネント、モック技術
コントローラー、なぜならエンドポイントを呼び出すニュアンスがあります
DAO、リポジトリ、テストベースの引き上げと移行を含む

この「パフペストリー」の概念が、複雑なアプリケーションをテストする手法を理解し、柔軟で強力なツールが仕事のためにどのように提供されているかを感じるのに役立つことを願っています。もちろん、ツールが優れているほど、より熟練した作業が必要になります。

あなたの仕事と素晴らしいスキルをお楽しみください！

サンプルコードは、github.comのリンクから入手できます：https： //github.com/denisorlov/examples/tree/main/unittestidea

パフペストリーの原則

それは意図されていません...

主な使命

しかし、くそー、どうやって？

パフペストリーの原則

軌道に乗って ...

More articles: