輝きと貧困テストの自動化

一般に、自動テストの存在は絶対に良いことです。 開発者がテストを作成する場合、テストは多ければ多いほど良いです。 同時に、実際にはそれらは頻繁に書かれておらず、すべてのテストは手動で行われます。



この状況を、開発者の無能、愚かさ、平凡な怠thisのせいにしないでください。 手動テストと比較して、自動テストには利点と明らかな欠点の両方があります。 プラスだけがある場合は、何も話すことはありません。

自動テストの利点

自動テストには、手動テストに比べていくつかの重要な利点があります。



安価 -自動テストの実行は、手動テストよりも常に数桁安くなります。 自動テストの開発は 、 1回限りの手動テストよりも確かに高価です。



疲れ知らず -自動テストは何度でも実行でき、無制限の稼働日があり、疲れず、病気になりません。



速度 —自動テストは、同じ手動テストよりもはるかに高速に実行されます。 もちろん、比較的遅いテストもありますが、これはルールを確認する例外である可能性が高くなります。



正確性 -自動テストは、スクリプトに記述されている内容をすべて詳細に検証します。 気が散ったり、混乱したり、忘れられたりすることはありません。



包括性 -自動テストにより、膨大な数のシナリオをカバーし、手動テスターが偶然の場合を除いて到達できないようなアプリケーションの隅にある誘導エラーを見つけることができます。

手動テストの利点

ただし、手動テストは、多くの点で自動テストよりも優れています。



敏ility性 -初めて手動で何かをチェックすることは迅速かつ簡単です。 最初に自動テストを開発する必要があります。 ほとんどの場合、これは手動検証よりもはるかに遅くなります。



柔軟性 -手動テストははるかに多様に実行でき、テスト方法の変更はほとんど費用がかかりません。 Safariでテストしましょう。Chromebookでは問題ありません。IE6では問題ありません。仮想マシンを起動する必要がありますが、それも可能です。



適応性 -変化にすばやく適応する能力。 製品が劇的に変化し、すべてが以前とはまったく異なる動作を開始すると、手動テスターは以前のテスト方法を簡単に忘れることができます。 彼らは今何があるのか​​を単純にテストします。 同じ状況での自動化されたテストでは数千のエラーが発生するため、先に進む前に修正する必要があります。



創造性 -手動テストにより、これまで知られていなかった、さらには暗示されていなかった問題を見つけることができます。



意味 -それぞれが完全に正しい場合もありますが、人々はこれらのことを一緒にすると意味がないことをはるかに容易に理解します。



表現力 -「何も機能しない」レベルで問題を見つけるだけでは不十分です。それが何であるかを正しく説明し、開発者の追加の質問に答えることが重要です。 そして、この点において、人々は自動テストよりも優れています。



信頼性 -私たちが人々のために書くアプリケーションのほとんどは、それが人々が彼らをテストするのに最も適している理由です。

パラドックスのテストの華やかさ

テストについて、特に完全なテストについて言えば、少しずるいです。 明らかに、 すべてを検証することは不可能です。



実際にできることは、 十分なテストを実行することです。 その結果、ほとんどのユーザーが問題に遭遇しないと主張できる可能性があります。



テストに1日費やした後、満足したユーザーの90％を達成します。 1週間のテスト-99％、1か月のテスト99.5％。 より少ない結果を達成するために、私たちはますます多くの時間を費やしています。 これは実用的ではありません。



問題を迅速に修正することで、利用可能なすべてのリソースを投資して完全なテストカバレッジを達成するよりもはるかに高品質の製品を実現できます。 ポイントは、力の適用のバランスを見つけることです。



手動でテストすると 、特にローカルで予測可能な部分でアプリケーションが徐々に変化する場合、 迅速に開発する必要がある場合に、より多くの利益が得られます 。 その理由は、同じテストを自動化するよりも、手で変更を確認する方がはるかに高速だからです。



自動テストにより、短距離で非常に小さなリターンが得られます 。 テストを作成するか、作成しないかを決定するそれぞれの瞬間に、2番目が常に望ましいです。



状況は長期的に根本的に変化しています。 アプリケーションコードは、死なないようにリファクタリングする必要があります。 プログラマーがすべてをやり直したとき-テスターはすべてをチェックする必要があります。 回帰テストの全サイクル。 一週間？ 二人？ 月？ さらに悪いことに、プログラマーはキーライブラリのバージョンを更新しました。 仕事の日、すべてがコンパイルされているようです-素晴らしい！ それでも、テスターはすべてをチェックする必要があります。 狂気 これを数回繰り返した後、誰もが将来同様の状況を回避するために何でもできるようになります。 安定した基本レベルの品質を確保するには、テスト自動化に投資する必要があります。



残念ながら、自動化されたテストは常に解決策とは限らず、時にはそれ自体が問題になることもあります。

貧困テスト自動化

問題 ：何回も何回も失うことなく、アプリケーションを完全かつ迅速にチェックできる必要があります。



解決策 ：これをすべて行う自動テストを作成します。



しかし、それほど単純ではありません。



テストの作成は開発であり、コアビジネスロジックの開発とまったく同じです。 リソースとスキルが必要です。 テストでアプリケーションコードの質の高いカバレッジを提供することにより、開発自体も同時に遅くなります。 そして、10％ではなく、2倍、3倍、またはそれ以上減速します。



速度は相対的な概念です。 もちろん、すべてのチェックがローカルで行われる場合、特定の各テスト、特にクリーンなユニットテストは非常に迅速に実行されます。 統合テスト、RESTテストも比較的高速です。 100ミリ秒は、セレンテストの場合は1秒でも数十秒でも、手動テストと比較しても何もありません。 しかし、テストの数がわずかでもかなりの場合、高速テストは非常に遅くなることが判明しました。 5分でテストを実行しますか？ 30分？ 三時？ 二日？ ビジネスロジックを完全に網羅することさえできなかったため、すべてのテストを実行するのではなく、テストを毎回実行しないという問題が深刻に発生します。



注 ：ハードウェアに投資することで、テストを大幅に加速できます-個別のサーバー、10台のサーバー、50台などを割り当てます。



ツールキットが悪いです。 主流のプログラミングプラットフォームはどれも、テストをできるだけ簡単かつ完全に開発する機能を提供するようには設計されていません。 Javaでは、すべてのテストフレームワークはサードパーティのライブラリです。 テストの実行、チェック、モックオブジェクトの作成-これらはすべてありますが、一部とプラットフォームの外にあります。 Goでは、テストフレームワークが最初に言語のエコシステムに既に追加されていますが、これはテストの開始に過ぎません。 テストを作成するための適切なツールを選択することは、対処する必要がある別の問題です。



あまり良くない 。 テスト-同じ開発者が書いた同じコード。 また、エラーや他のコードと同じ問題もすべて含まれています。 テストでは何もチェックされないことがあります。 テストもリファクタリングする必要がある場合があります。 倒れたテストで問題が何であるかを理解することは非常に難しいことが起こります。 実際にエラーがない場合、テストはそのようになります。



ブロック変更 。 本質的に、テストは何も変更されていないことを確認するように設計されています。 何かがうまくいかない場合-これはバグです。 しかし、ビジネスロジックが変更されると、変更が正しく、新しい要件を完全に満たしても、テストはそれについて何も知りません。 複数のルールを変更すると、特にカバレッジが非常に良好な場合、数百のテストではなくても数十のテストを修正する必要が生じる場合があります。



リファクタリングを制限します。 また、ビジネスロジックが変更されず、コードに表面的な変更のみが発生した場合でも、テストをリファクタリングする必要があります。 これは、メインコードの5箇所とテストの80箇所を修正する必要があるという事実につながる可能性があります。 この状況にいる人は誰でも考えるでしょう。メソッドの名前を変更する以上のことをする価値があるのでしょうか。



Sisypheanの労働とは、テストによって開発が変わるもの、コードが書かれる前にテストが書かれたとき、または少なくとも途中で書かれたものです。 問題をより深く理解し、ソリューションを最適な方法で実装する方法を理解するにつれて、有能な開発者はコードを書く過程でコードをリファクタリングします。 ただし、コードの変更に加えて、コードと同時にテストを作成する場合は、テストも変更する必要があります。 そして、完成したコードのリファクタリングとは異なり、作業中のコードのリファクタリングは通常はるかに大きく、テストで必要な変更が適切であることを意味します。 そしてそう-コードがレビューに入る前に何度も。 ゴミの半分の作業時間は簡単です。



テストの数は欺de的です。Webインターフェイス、REST API、ビジネスロジック、ユニットテストの合計3000テストは、1000の状況でチェックできます。 それ以外はすべて複製です。



自動回帰は 、主な考えに反して手動をキャンセルしません 。 それは、自動テストが多くのことをテストするからです。すべてではありません。 しかし、彼らが正確に何をチェックし、何をチェックしないのか-誰も知りません。 登録を確認する必要があります。 また、18 927個のテストもあります。 それらのいずれかが赤である場合-「すべてが問題ない」場合は、開発者にタスクを返すことができます-彼らに理解してもらいます。 すべてのテストが緑色の場合、手動テストの責任者がロギングロジックが自動的にチェックされ、手動でチェックする必要があることを確認するまで、これは何の意味もありません。 そして、2万件近いテストがあります-それを理解することは不可能です。 結果-すべてを手動で確認する必要があります。



プラスチックの窓を売ったり、ビリヤードを教えたり、コーヒーを作ったりするために開発を離れる人もいます（これらはすべて実際のケースです）。



次の投稿では、 Wrikeで自分自身や他の人々の間違いからどのような結論を出したかを説明します。



ドミトリー・マモノフ



開発部

マスターのマージ部門、

gitの作業部門、

bashコンソール1カテゴリーの主要なオペレーター