単体テスト：何を、どのように、いつテストするのか？

ソフトウェアコードのテストは骨の折れる複雑なプロセスです。 その中の作業の大部分は、単体テストによって行われます。 それらが「緑色になる」まで、さらにテストする意味はありません。



ユニットテストを正しく書く方法は？ 100％のカバレッジを追いかける価値はありますか？ エンジニアは実際にどのような困難に直面していますか？ Marc PhilippとVsevolod Brekelovは彼らの経験を共有しています。









Marc Philippは、Javaテスター向けのツールであるJUnit 5フレームワークの主要な開発者の1人です。 現在、彼はドイツの会社LogMeInでクラウドSaaSソリューションのエンジニアとして働いています。



Vsevolod Brekelov-Grid DynamicsのシニアQAエンジニアは、5年以上テストを行っており、テストの自動化をゼロから構築した経験があります。



-単体テストに関する記事では、通常、テスト方法と計算機のクラスが例として挙げられています。 そのような例は、実際のタスクの複雑さを示すことができますか？ フル機能のプログラムのテスターは何に直面しますか？



Marc Philipp：実際、計算機を使用した例では、実際のタスクの複雑さを示すことは不可能です。 記事で選択されているため、読者は複雑なコードを解析することなく単体テストのアプローチを理解することに集中できます。 これらの例は非常に単純ですが、ユニットテストの基本的な考え方と原則をよく示しています。 実際には、単体テストが実行されることを考慮して、テスト済みのコードを最初に記述する必要があります。 これを確実にする1つの方法は、コードを記述する前に、またはほぼ同時にテストを記述することです。 テストに適したコードがある場合、単体テストの作成は電卓の場合ほど複雑ではありません。



Vsevolod Brekelov：実際のタスクの複雑さは実際の問題でしか理解できないと思います。 真剣に、非常に重要な例が詳細に検討されている良い記事があります。 現実に近づくのに役立つと思います。



たとえば、「Javaの単体テスト」というリクエストでは、 Habréに関する記事をすばやく見つけることができます 。 それはずっと前に公開されましたが、その関連性を失っていません。



作業の機能に関しては、次のテスターのグループを選び出します（誰かを怒らせないでください）。

• バックエンド-システム、統合、コンポーネント、単体テストを作成できます（なぜですか？）。
• フロントエンド-e2eテストとコンポーネントおよびユニットテストの両方を作成できます。
• DB-彼らはデータ/データベース自体のテストに従事しています。
• パフォーマンス-ここでは明らかなようです。
• インフラストラクチャ-「near-devobsnye」問題の詳細。
• モバイルテスト（iOS、Androind、IoT）-今では、このようなエンジニアを分離することは非常にファッショナブルになりましたが、私の意見では、すべて同じバックエンド/フロントエンドです。

これらの人々は通常、ソフトウェア自体をテストするだけでなく、要件とプロセス自体もテストします。 確かに、彼らはこれに最も頻繁に正式にアプローチしますが、これは私の意見では間違っています。



プロセスに注意を喚起したいと思います。 私の練習では、バグと、不要なものを実装するための時間の主な無駄がそこから成長するため、各テスターは開発プロセスの構築に精通している必要があると考えています。



-各テストで1つのことを確認する必要があります。 実際には、この条件をどの程度完全に満たすことができますか？ どのフレームワークを使用しますか？



Marc Philipp：単体テストを作成するとき、通常、テスト対象の問題領域の等価クラスからの入力のサンプルが1つ取得されます。 もちろん、最初にこれらの同じ等価クラスを定義する必要があります。 各テストでは、テストに関連するプロパティに対してのみアサーションを追加します。 同じアサーションを新しい各テストにコピーして貼り付けないでください。 ユニットのパフォーマンスに影響を与える依存関係がある場合は、スタブまたはモブを使用してテストの独立性を維持することを検討してください。



JUnit 5の単体テストの多くは、モックフレームワーク（この場合はMockito）によって作成されたモックを使用します。 上で言ったように、それらは分離されたコードをテストするのに非常に便利です。 この場合の主なタスクは、mokが実際のコードと同様に動作することを確認することです。 そうしないと、テストは無意味になります。



Vsevolod Brekelov：はい、意見があります。1つのユニットテスト-1つのアサーションです。 実際には、これはめったに見ませんでした。 これがチームの哲学だと思います。 複数のアサーションには場所があります。



コンポーネントテストではなくユニットテストを実施する場合、すべての依存関係（moki、スタブ-すべてはあなたの手にあります）を分離します。 私の意見に問題はありません。 もしそうなら、StackOverflowは間違いなく役立ちます。



Java / JavaScript（Angular）で記述しているため、通常の一般的なツールを使用します。

Javaで-Mockito / EasyMock。 コンポーネントテストの場合、レスポンシブモックを作成することもお勧めです。 皆さんにアドバイスします。



JavaScript-ngMock。 ところで、コンポーネントテストの非常にクールなトピックはAngularPlaygroundです。



-「書き込み」プロジェクトを実装する際に、テストの人件費と財務コスト、および最終ソフトウェアの品質の間で妥協点を見つける方法 そのような場合の完全なテストの重要性を通常どのように主張しますか？



Marc Philipp ：私の経験では、テストをスキップして「書き込み」プロジェクトを保存することはできません。 単体テストの作成は、ソフトウェア開発の不可欠な部分です。 それなしでは、あなたのコードが本当にあなたがすべきだと思うことをやっているかどうかを知る方法がありません。 何が壊れたのか分からないため、すぐに修正することはできません。 UncleBobが言ったように 、「速く行く唯一の方法はうまくいくことです。」



Vsevolod Brekelov：単一の答えはないと思います。 むしろ、プロジェクトの経験と種類が役立ちます。 医療プロジェクトを行っている場合やロケットを構築している場合は、テストの重要性について話す必要はありません。 スタートアップを1週間見た場合-何をテストしますか？



突然のバグや誤って実装された要件を回避するために、プロセスを整理することが非常に重要です。 適切なプロセスとは何ですか？ もちろん、アジャイルマニフェストもあります。これは、プロセスを整理するときに多くの人が見るものですが、それでも何かがうまくいきません。 プロセスのためにプロセスを取得および構築できます。 または、 http：//programming-motherfucker.com/に従ってください。



主なことは、チームの開発者とテスターに​​適した要件を持つことです。 これは、彼らが何が起こるかについて同じ理解を持っていることを意味します。



-テストの時間と人件費を削減するのに役立つテクニックは何ですか？



マークフィリップ： 「テスト」という用語は、過剰な用語です。 単体テスト、手動テスト、パフォーマンステストなど、何でも意味があります...私の経験では、手動テスト、つまりテストケースをパスするための段階的な計画の手動実行は、本当に高価で、多くの場合、思ったほど効果的ではありません。 さらに、これらの退屈なテストの自動化は、ある程度しか意味がありません。 ただし、実際にはテストピラミッドに従う必要があり、これらのエンドツーエンド/ UIテストをあまり記述しないでください。 テストのほとんどは、実際のユニットテストである必要があります。非常に頻繁に実行できる独立したクイックテストです。 これらのテストの作成は、特にツールを知っている場合は比較的安価です。 これらは非常に信頼性が高いため、更新に時間を浪費することはありません。 膨大な数のコンポーネントが関係するため、UIおよび統合テストは常に脆弱になります。



Vsevolod Brekelov：良いトリックがあります-少ないコードを書いてください。



主なことは、プロセスと何を解決（またはテスト）するかを理解することです。

予算と時間を適切に評価することが常に必要です。 これはどういう意味ですか？ 100％のカバレッジに近い金額のお金を注ぐ余裕があるなら、なぜですか？ マスターはマスターです。



自動テストにお金がない場合（ご存じのように、主に長期にわたるプロジェクトで戦っています）、多くの手動テスターが選択肢です。



極端に行かない場合、最も一般的な間違いは、ユニットテスト、コンポーネントテスト、バックエンド、フロントエンド、DB、パフォーマンスなどの統合テストが書かれる前に、パルスを失う前にバッチでe2eテストを書くことです。 この傾向は、おそらくトレンディなBDDアプローチによるものです（私はそれらがあまり好きではありません）。 これはすべて何につながりますか？



「中毒」の第一段階-あなたの自動化は本当に働き始めます。 手動テストケースを自動テストケースに置き換えます。 テスターは喜び始めます。 マネージャーは、彼らが救おうとしていると考え始めています。



2度目-多くのテストがあり、何らかの理由で定期的に失敗するものもあります。 テスターはもはやあまり幸せではありません。 座って理由を理解する必要があります。 しかし、バグはまだクロールします。 そしておそらく、彼らは手動（おそらく猿）のテストによってQA環境にいるのです。



3度目-誰もがSeleniumに関する会議に参加し始め（これらの会議に反対することはありません）、Flakyテストの対処方法を学び、さまざまなソリューションを試します。 テストを並行して実行します。



4番目の学位は、50のエージェントで500のe2eテストを実行するためのスーパー階層全体を構築し、すべてが10分という短い時間で迅速に飛ぶようにすることです（もちろん、ここで誇張します）。 そしてまだバグがあります。



5度-私はそれを達成不可能と呼びます。 ほとんどのe2eテストは不要であることがわかります。 誰も書いたことのない他のテストが必要です。 たとえば、コンポーネントはバックエンドでテストするか、UIでもテストします。 それともシステムテストではないのでしょうか？ それともレイアウトテストですか？ それとも、{username}オプションですか？



もちろん、すべてが「正しく」行われるプロジェクトがあります。 しかし、多くの場合、テストする必要があるものを理解していないという問題があります。 十分な理解があれば、時間とお金を節約できます。 さらに、製品の品質を向上させます。



-開発ツールの開発とコード作成のアプローチは、テスターのツールとアプローチにどのように影響しますか？ どの革新がそれをより簡単にしますか

単体テスト（たとえば、メソッドをラムダ関数として表す）



Marc Philipp：新しいツールは、開発者に柔軟性を与えることで開発者の生活を楽にします。 ただし、最終的に、テストをメソッドとして提示するか、ラムダ関数として提示するかは問題ではないと思います。 何をテストし、どのようにテストするかを理解することが最も難しい部分です。



Vsevolod Brekelov：ツールとアプローチの開発は、使用すればプラスの効果があります。 誇大広告の技術や職場でのアプローチを常に適用できるとは限りません。 私たちはまだビジネス上の問題を解決しています。 しかし、常にバランスを見つけることができます。



テストを簡単にするのは奇妙な質問です。 テクノロジーは人生を大きく促進することはできないと思います。 新しいもの（テクノロジー、ツール）を使用するためには、チーム全体で調査し、ある種の「ポリシー」、コードスタイルを受け入れる必要があるためです。 長い目で見ればこれはもちろん生活を楽にすることができますが、短距離では労働集約的であるため、あまり有用ではありません。



ところで、Kotlinに切り替えるオプション（Javaテストについて話している場合）は良いアイデアかもしれません。 私はまだ練習で試していません。



言語の革新（ラムダやその他のユーティリティ）に関しては、もちろんこれはすべて良いことですが、測定する必要があるので、どれほど簡単に生活が楽になるかを言うのは難しいです。 私は測定しませんでした。 しかし、進歩の反対者として私を書き留めてはいけません、私は何か新しいことを学ぶ/使う習慣が常に存在するべきであると信じています。 これは通常の継続的な改善ストーリーです。



-単体テストで生産プロジェクトをどの程度カバーしていますか？ 100％のカバレッジに時間を費やす価値はありますか？



Marc Philipp：使用するプログラミング言語とフレームワークによっては、プロジェクトにロジックを含まない定型的なコードが含まれている場合があります。 しかし、私の意見では、そのような部分に加えて、すべてのコードに対して単体テストを作成する必要があります。 したがって、私は90％以上のカバレッジをお勧めします。



Vsevolod Brekelov：私が仕事をしなければならなかったプロジェクトでは、ほとんどの場合、開発者はテストを90％でカバーしようとします。 時間に見合う価値があるかどうかは通常、管理者が決定します。 私はマネージャーではありませんが、私にとっては単体テストは非常に良い習慣です。このためのリソースがある場合は、100％のカバレッジを得るのが良いでしょう。



覚えておくべき主なことは、残念ながら100％のカバレッジはバグがないことを保証するものではないということです。



カバレッジが90％から100％のレースよりも有用と思われるものから、突然変異テストを作成することができます。 2012年の記事に関して、新しいことは何も言いません。 しかし実際には、このアプローチが適用されていることはあまり見ませんでした（そして私自身も悔い改めています）。 それで、多分それは開始する時ですか？



-テストフレームワークは単体テストにどのように役立ちますか？ 彼らは仕事のどの部分を引き受けますか？ フレームワークを使用する場合、何を期待すべきではありませんか？



Marc Philipp：優れたフレームワークを使用すると、単純な単体テストを非常に迅速かつ簡単に記述できると同時に、より複雑なテストを実行するための強力なメカニズムを含めることができます。 たとえば、テストデータを準備し、多くのテストで同じロジックを再利用できる拡張ポイントを提供するのに役立ちます。 しかし、どのフレームワークがテストの対象を決定することはありません。 また、彼はあなたのプロジェクトを魔法のように改善して、テストしやすくすることもできません。



-単体テストが最も難しいコード要素はどれですか？ あなたの問題はどのように解決されますか？



Vsevolod Brekelov：依存関係が多いほど、ルーチンが多いほど、単体テストを書くのが難しくなります。 しかし、一般的に、正直なところ、特定の問題は見当たりません。 ユニットテストのトピックについては多数の本が書かれていますが、そのうちの1本は最後まで読んでいません。 たぶんそれが問題を抱えていない理由です。



たとえば、オブジェクトのコンストラクタに春雨のコードが含まれている場合、単体テストを書くことは困難ですが、その後、本を読むように仲間にアドバイスすることができます。

たとえば 、コードレビューのプラクティスを紹介します。



JavaScriptコードについては、ダイジェストの操作など、使用されるフレームワークに関連する可能性が高いため、さまざまな困難や驚きに遭遇する可能性があります（はい、私はJavaScriptが大好きです）。 AngularJS / Angular2 / Angular4のみを使用しました。 Angularチームは便利なテスト済みのフレームワークを作成しようと努力していますが、確かに解決策のある問題が発生することがあります。私たちはエンジニアです。

---

テストのあらゆる側面に関する膨大な情報が、近くのハイゼンバグの参加者を待っています。マークフィリップは、レポート「JUnit 5-Javaの新しいテストフレームワークとJVMのプラットフォーム」を読みます。



会議で他の重要な人物が何を話すかを知ることができ、傍観者の最も緊急の質問に答えることができます。