この記事の対象者
この記事では、従来のカスケードモデルに取り組んでいるチームや、柔軟な方法論（アジャイル）を備えたチームでユニットテストプロセスを実装する方法について説明します。 私たちの組織では、どのチームでも、プロジェクトマネージャーはプロセス全体とスプリントをタスクで満たす責任があり、各タスクに必要なテストの種類の議論に参加し（共同ブレインストーミング）、最終決定を下します。 したがって、私の記事の主な目的は、チームのプロジェクトマネージャー（そのような役割を担っているという理由のみ）と、勤務中に同様のタスクに従事しているすべての人々です。
これはどのチームに適していますか？
2種類のチームに単体テストを実装するプロセスを紹介したいと思います。 柔軟な方法論に従って作業するチーム、および自分自身でカスケードスタイルの作業を選択したチーム。
以下の図は、役割コマンドの概略図を示しています。
このスキームから、プロダクトホルダーからタスクを受け取ったプロジェクトマネージャーは、プロセスのすべての参加者とタスクを調整し、結果に応じてスプリントに含める（または含めない）と結論付けることができます。
単体テストは通常のテストとどのように異なりますか？
ここで、ユニットテストとは何か、そして私たちのケースではどのように実装されているかを説明したいと思います。
そもそも、ユニットテストのスペシャリストはそれぞれの分野のエキスパートです（これは特定のシステムとして最もよく理解されています）。 幅広いバックグラウンドと必要な技術スキルを備えています。 各システムには独自の知識、Pl / SQLの専門知識、特定の開発言語、特定のシステムでの長年の経験が必要です。 フロントエンドシステムには影響しません。 私たちは、ミドルレベルシステムとバックレベルシステムを監視します。
おそらく、機能の開発/改良がさまざまなレベルでのシステムの変更を含むことは誰にとっても秘密ではありません。 各ユニットテスターは、システム内でのみ新しい機能をテストします。 コードをテストし、インターフェイスを使用せずに契約を遵守します。 テストデータのサンプリングも盲目的に行われませんが、出力パラメーターの変動の最大数をカバーする最小データセットの原則に基づいています。 私たちにとって主なことは、記述されたコードの機能的および技術的な正確さです。
単体テストと他のタイプの最初の違いは、コードを見て、固定接点/出力パラメーターの不変性に焦点を合わせていることです。 それらが修正され、違反されていない場合、システム統合のプロセスで、機能は問題なくオンになります。
そして2つ目-これは、試験によるテストの改善時間の大幅な短縮です。 統合テストでは、機能全体を調べますが、部分的に確認します。 単体テストはどのようなタスクを解決しますか？ 上記に基づいて、線を引いて質問に答えることができます：単体テストはどのタスクを解決しますか？
- 「彼らの」システムのコンテキストでの機能テスト。
- 正しいデータを処理するだけでなく、エラーや例外を生成するためのコードの技術的なテスト。
- 重大なバグや障害をブロックすることなく、機能を統合テストに移行します。
これらはおそらく強調したい3つの主要なポイントです。 開発プロセス中またはエラー発生直後に見つかったエラーが修正され、より速く、痛みが少なくなるという事実について長い間話すことができますが、私なしでこれを知っています。 開発者は、コードレベルで具体的に説明されているバグを知っているだけでなく、プロセス内の一般的なバグよりもはるかに簡単に認識します。
単体テストを実装する利点
これをすべて読んだ後、疑問が生じます。単体テストを実装する利点は何ですか？ 前に、チームの2つの作業スキームを説明しましたが、ここでそれぞれのスキームを参照して説明します。
アジャイル手法に取り組んでいるチーム。 次の図は、このタイプのチームの単体テストの場所を示しています。
この場合、コードが実際に「なめられ」、開発の最終段階で単体テストが接続され、すべての基本機能が開発されました。 モジュラーテスターは、バックオフィスシステムまたは統合バスでの開発が正しく実行されているかどうかを確認するために、最初からプロセスを開始する必要はありません。
開発の開始前に、プロセスのすべての参加者は、スプリントでどの機能を使用したかを理解し、エンドユーザーの観点からどのように機能するかを理解します。 その結果、スペシャリストがテストを開始する前に費やす必要がある時間はゼロに近いという結論に達しました。 テストケースを記述する必要はありません（それがどのようなものであるかを急ぐ必要はありませんが、知識の転送などはどうでしょうか）。すぐにコードをクロールして続行します。
開発が完了した後、タスクのテストをさらに進めると、既にテスト済みであり、重大なバグは含まれていません（開発側と分析側の両方から）。 そして、重要ではないのはどうですか？ このようなバグは見つかりましたが、非常にまれであり、通常は非常に特定のテストデータに関連付けられています。 そのような各ケースは処理され、チームのウィキに入力されます。 しかし、それが出てくるすべての利点ではありません！
チームに自動化されたテストユニットがあれば（そして1つあれば！）、出力に自動化されたユニットテストもあります！ これは、選択したテストフレームワークでの一連のテスト、または単一のパックに結合され、オンデマンド/スケジュールで呼び出される一連のスクリプトです。 さらに、これらのテストは、自動化された単体テストと自動化部門のテストの両方を含む特定のリグレッションパックに含まれており（少し後でそれらの違いを検討します）、スプリントタスクが戦闘に送信される前に実行されます。 彼が私たちに与えてくれたものは、私が明確に、そして私の説明なしで考える。
単体テストと並行して統合テストを統合することもできます。 テストチームが最前線のシステムを介して中間システムまたはバックシステムに到達する限り、テストは70〜80％以上完了します。 つまり コードの編集に伴うダウンタイムは発生しません。 これはアジャイルチーム向けです。
次に、カスケードベースで機能するチームの状況を見てみましょう。 単体テストを有効にした回路は次のようになります。
ここでは、ユニットの終了後に統合テストが開始されることがわかります。 これは、すでに検討されているオプションとの主で根本的な違いです。 タスクが単体テストから終了するまで、統合テストは開始されません。 テストシナリオ、テストデータの準備中です。
それ以外の場合、プロセスは変更されず、アジャイルコマンドと同じ出力データと同じバンズになります。
もう少し上に、自動化された単体テストが自動化チームの自動化テストとどのように異なるかについてお話しすることを約束しました。 違いは非常に単純で、表面上です。 99％では、自動化チームは特定の改良ではなくプロセスを自動化します。
インターネット銀行を通じてカードの情報を要求する例を考えてみましょう。 自動化チームは、フロントレベルでケースを作成します（ログイン/タブ、カードを選択/ボタンをクリックして残高をリクエストします）。 出力では、情報があるか、ないかのどちらかを取得します。 非常にまれなケースでは、エラーが発生したシステム/機能を理解します。
自動化された単体テストはどうですか？ 同じ例を見てみましょう。 テストはインテグレーションレベルで記述され、入力済みの契約（最前線システムから引き出された）を受け取り、変換、ソースシステムの呼び出し、結果の処理、およびレシーバーシステムに対する回答の生成が行われます。 すべての点でチェックがあります。 ソースが必要なものすべてを正確に返したかどうかを確認することは残っていますか？ 次に、このパズルの解決策を知っています。 したがって、1つではなく2つのテストを取得します。これらのテストは数倍速く実行され、エラーの場合に包括的な知識を提供します。 ログの分析と分析に時間を無駄にしません。
単体テストの実装方法
単純なチーム全体が長い間すでに災害になっていることに同意しますか？ したがって、ユニットテストの中間段階をチームに導入することの主な利点は非常に明白です。 プロセスのすべての参加者と最終結果に興味がある人にそれを伝えるだけです。
最初に、誰もがそれがどんな動物なのかを理解しているわけではないことを当たり前のことと考える必要があります-ユニットテスト チーム間で何らかの説明作業を行い、そのようなチームと従来のテスターとの違いに関して上記で説明したすべてを提示できるようにする必要があります。
準備作業の後、主なタスクは、少なくともテストモードで単体テストを使用してアプローチの実装を達成し、これにリソースのごく一部を割り当てることです。
新しいチーム編成によるいくつかのデモスプリントの後、以下がこのアプローチの有効性の証拠となります。
- 単体テストフェーズで見つかった欠陥。 （ここで、以前に見つかった同じレベルの欠陥との類似性を引き出し、それらが修正されるまでチームがアイドル状態だった時間の違いを示すことができます）
- 統合テストに転送された機能の品質。
- 開発者が理解できる言語で話す開発者の反応。
- ユニットテストのプロセスに自動化を追加する場合、既製の自動化されたユニットテストにより、将来の手動の機能チェックの部分を回避できます。
結論：
その結果、上記のすべての実装操作が完了すると、ユニットテストはプロセスの不可欠な部分になり、次のことが可能になります。
- 見逃した欠陥の数を減らします。
- エンドユーザーに新しい機能を導入するプロセスをスピードアップします。
- 手動テストチームと開発の間の相互作用のプロセスを償却します。
- インターフェイスパーツの変更に依存しない低レベルの自動テストの累積データベースを作成および維持します。