自動テストの欠点は何ですか？
このサイトには、自動テストから得られる利点についての情報を提供する多くの質問があります。しかし、私はコインの裏側を表すものは何も見ませんでした：欠点は何ですか？人生のすべてがトレードオフであり、特効薬はないので、自動テストを行わない正当な理由が確かにあるはずです。彼らは何ですか？
ここに私が思いついたいくつかがあります：
- 特定の機能について、初期の開発者時間がさらに必要
- チームメンバーのより高いスキルレベルが必要
- ツールのニーズを増やします（テストランナー、フレームワークなど）
- 失敗したテストが発生した場合、複雑な分析が必要です-このテストは私の変更が原因で廃止されたのですか、それとも私が間違いを犯したことを示しているのですか？
編集
私は自動テストの大いなる支持者であり、それを行うと確信しているようには見えません。私は不利な点が何であるかを理解するために探しているので、私がそれを主張するために会社に行くとき、私は次の想像上の銀の弾丸を投げているようには見えません。
また、私は上記の私の例に異議を唱える人を探していますではありません。私はいくつかの欠点（すべてにトレードオフがある）が（== --- ==）必須であり、それらが何であるかを理解したいと思っています。
あなたはほとんどの最も重要なものを釘付けにしました。私はいくつかのマイナーな追加と、実際にテストを成功させたくないという不利な点があります（実際にテストを望まない場合）（以下を参照）。
開発時間：テスト駆動開発では、これは単体テストですでに計算されていますが、統合およびシステムテストが必要です。これには、自動化コードも必要になる場合があります。一度書かれたコードは通常、後のいくつかの段階でテストされます。
スキルレベル：もちろん、ツールをサポートする必要があります。しかし、それはあなた自身のチームだけではありません。大規模なプロジェクトでは、チームの製品と他の製品のインターフェースをチェックするためのテストを作成する別のテストチームがいる場合があります。より多くの人々がより多くの知識を持つ必要があります。
ツールの必要性：あなたはそこにスポットを当てています。これに追加することはあまりありません。
失敗したテスト：これは本当のバガーです（とにかく私にとって）。さまざまな理由がいくつかありますが、それぞれに欠点があると考えられます。そして最大の欠点は、これらの理由のどれが実際に失敗したテストに当てはまるかを決定するのに必要な時間です。
- 実際のバグのために失敗しました。 （これはもちろん有利なので、完全を期すためです）
- テストコードが従来のバグで記述されているため、失敗しました。
- テストコードが製品の古いバージョン用に作成されており、互換性がなくなったため、失敗しました
- 要件が変更され、テストされた動作が「正しい」と見なされたため、失敗しました
失敗しないテスト：これらも不利であり、かなり悪い場合があります。それは主に、あなたが物事を変えて、アダムが答えたものに近づいたときに起こります。製品のコードで何かを変更しても、テストでそれがまったく考慮されていない場合は、この「誤った安心感」が得られます。
失敗しないテストの重要な側面は、要件の変更により、以前の動作が無効になる可能性があることです。トレーサビリティが適切であれば、要件の変更をテストコードと一致させることができ、そのテストを信頼できないことがわかります。もちろん、このトレーサビリティを維持することはさらに別の欠点です。そうしないと、テストは失敗せずに終了しますが、実際には製品が動作することを確認します間違って。道のどこかでこれはあなたを襲います..通常、あなたがそれを最も期待しないとき/場所。
追加の導入コスト：自分のマシンで開発者として単体テストを実行するだけではありません。自動テストでは、誰かがあなたの仕事を壊したときを知るために、中央の場所で他の人からのコミットでそれらを実行したいです。これはいいことですが、セットアップして保守する必要もあります。
私たちのチームで自動テストを始めたばかりで、最大の欠点は、自動テストを考慮して設計されていないレガシーコードに適用するのが非常に難しいことです。間違いなく、長期的にはコードが改善されますが、健全性を維持しながら自動テストに必要なリファクタリングのレベルは、短期的には非常に高い障壁です。短期的なコミットメントを満たすための単体テスト。言い換えれば、すでに技術的負債が深い場合、クレジットカードを完済することははるかに困難です。
おそらく最も重要な欠点は... テストは製品コードですです。記述するすべてのテストでは、コードベースにコードを追加します。コードベースは、維持およびサポートする必要があります。そうしないと、結果を信じられないテストにつながるため、他に選択肢はありません。誤解しないでください-私は自動テストを大いに支持しています。しかし、すべてにコストがかかり、これは大きな問題です。
これらが完全に適用可能な欠点であるとは言えませんが、私が最も当てはまるものは次のとおりです。
- 複雑なエンタープライズアプリケーションでテストをセットアップするのにかかった時間。
- 誤って失敗する古いテストの処理、つまり、システムが進化し、今ではテストが間違っています。
- 斑状または不明なテストカバレッジからの誤った信頼。
パッチのテストカバレッジは、誤った安心感につながる可能性があります。リファクタリングを行い、テストを使用してそれが有効であることを証明する場合、テストがこれを証明できることを何が証明しましたか？
テストの作成にかかる時間は、時々問題になります。自動テストには単体テストだけでなく、ユースケーステストも含まれます。これらはより広くなる傾向があり、コンテキストを必要とします。
もちろん、私の視点は、単体テストより古いアプリケーションからのものです。
彼らの主な問題は、誤った安心感を提供できることです。あなたがユニットテストを持っているからといって、それが実際に 何かをしている であるとは限りません。これには、要件を適切にテストすることが含まれます。
さらに、自動テストにはバグ自体も含まれる可能性があるため、問題が ユニットテスト自体にテストが必要かどうか 必ずしもそうではない何でも達成する。
自動化テストには多くの利点がありますが、独自の欠点もあります。いくつかの欠点は次のとおりです。
- 自動化テストスクリプトを作成するには、熟練が必要です。
- テストスクリプトのデバッグは大きな問題です。テストスクリプトにエラーが存在する場合、致命的な結果を招くことがあります。
- 再生方法の場合、テストのメンテナンスにはコストがかかります。 GUIで小さな変更が発生しても、テストスクリプトを再記録するか、新しいテストスクリプトに置き換える必要があります。
- テストスクリプトがより多くの画面をテストする場合、テストデータファイルのメンテナンスは困難です。
上記の欠点のいくつかは、自動化スクリプトから得られる利点から差し引かれることがよくあります。自動化テストには長所ととうもろこしがありますが、世界中で広く採用されています。
私は最近質問しました ゲーム開発のテストに関する質問 -これは私がこの問題について知っていた方法です。そこでの答えは、いくつかの奇妙な、特定の欠点を指摘しました：
- コードが必要な場合が高度に結合されている場合、コストがかかります 。
- ユーザーへの出力を分析する必要があり、コード結果がより広いコンテキストでのみ意味をなす場合、さまざまなハードウェアプラットフォームに注意する必要がある場合は困難です 。
- IとUXのテストは非常に難しい 。
- 特に、自動テストは、非常に低コストの（または無料の）ベータテスターの束よりも高価で効果が低くなる可能性があります 。
4点目は、私の経験を思い出させてくれます。私は、単体テストが強く推奨されている、非常に無駄のない、XP指向のスクラム管理会社で働いていました。しかし、よりスリムで官僚的なスタイルへの道のりの中で、同社はQAチームの構築を怠っただけで、テスターはいませんでした。そのため、テストカバレッジが> 95％であっても、一部のシステムを使用して、お客様は些細なバグを頻繁に発見しました。だから私は別のポイントを追加します：
- 自動テストmayは、QAとテストが重要ではないと感じさせます。
また、私は当時、ドキュメンテーションについて考えていて、2つをテストするために（ある程度まで）有効である可能性がある仮説を議論しました。コードが急速に進化し、そのような速度でドキュメントを作成するのはかなり難しいと感じただけなので、重い、簡単に時代遅れのドキュメントを書くよりも、コードを読みやすくすることに時間を費やす方が価値があります。 （もちろん、これはは適用されませんはAPIに適用されますが、内部実装にのみ適用されます。テストには同じ問題が少しあります。テストしたコードと比較すると、書き込みが遅い。 OTOH、それはテストが古くなっていることを警告するので、それはより小さな問題ですが、あなたがそれを再読しない限りあなたのドキュメントは沈黙します非常に、非常に慎重に。
最後に、私が時々見つける問題：自動テストはツールに依存している可能性があり、それらのツールは不十分に記述されている可能性があります。少し前にXULを使用してプロジェクトを開始しましたが、そのようなプラットフォームの単体テストを作成するのは面倒です。 Objective-C、Cocoa、Xcode 3を使用して別のアプリケーションを開始しましたが、そのテストモデルは基本的には一連の回避策でした。
自動テストの欠点について他の経験がありますが、それらのほとんどは他の回答に記載されています。それにもかかわらず、私は自動テストの熱烈な支持者です。これにより、多くの作業と頭痛の種を節約でき、私は常にデフォルトでそれをお勧めします。自動テストの利点と比較した場合、これらの欠点は単なる詳細にすぎないと判断します。 （異端をコメントした後は、常に自動ダフェを避けるために信仰を宣言することが重要です。）
言及されていない2つは次のとおりです。
- 大規模なテストスイートを実行するのにかかる時間の長さ
私はテストが遅いため、テストの実行に半日かかった自動QA作業の一部でした。テストの作成に注意を払っていない場合、テストスイートもこの方法で判明する可能性があります。 「ああ、私は修正をコミットしましたが、正確であることを証明するのに4時間かかります」という時間を管理するまで、これは大したことではないように思えます。
- いくつかのテスト書き込み方法の脆弱性
一部のテスト方法（UIの自動化など）は、向きを変えるたびに壊れるようです。たとえば、スクリプトがボタンが表示されるのを待っているためにテストプロセスがハングする場合は特に苦痛ですが、ボタンの名前は変更されています。
これらは、適切なテストプラクティスで回避できる両方です。テストスイートを高速に保つ方法を見つけます（マシン/ CPU間でテスト実行を分散するなどのトリックを実行する必要がある場合でも）。同様に、テストを作成する虚弱な方法を回避するように注意することもできます。
もう1つ、誤った安心感を追加したいと思います。
非常に小さな明確な問題セットを超えて、包括的なテストを作成することはできません。自動化されたテストではテストされないバグがソフトウェアに存在する可能性があります。自動テストに合格すると、コードにバグがないことを想定することがよくあります。
管理/ベンチャーキャピタリストを説得するのは難しい
- testautomationは初期費用を増加させます。
- テストの自動化により、市場投入までの時間が増加します。
- テスト自動化の利点は、中間およびログタームにあります。激しい競争は短期的な利益にさらに焦点を当てています。
詳細は Market Driven Unit Testing を参照してください。