自動テストの欠点は何ですか？

このサイトには、自動テストから得られる利点に関する多くの情報を提供する多くの質問があります。しかし、私はコインの反対側を表すものを見ませんでした：欠点は何ですか？人生のすべてはトレードオフであり、特効薬はありませんので、自動テストを行わない正当な理由が必ずあるはずです。彼らは何ですか？

ここに私が思いついたいくつかがあります：

• 特定の機能に対して初期開発者の時間がさらに必要です
• チームメンバーの高いスキルレベルが必要
• ツールのニーズを増やす（テストランナー、フレームワークなど）
• 失敗したテストが発生した場合に必要な複雑な分析-このテストは私の変更により廃止されたのですか、それとも間違いを犯したと言っているのですか？

編集
私は自動化されたテストの巨大な支持者であると言っておくべきであり、私はそれをすることを納得させるつもりはありません。欠点が何なのかを理解したいと思っているので、会社に行って主張するとき、次の想像上の銀の弾丸を投げているようには見えません。

また、上記の私の例に異議を唱える人を探していないことを明確にしています。私は、いくつかの不利な点（すべてにトレードオフがある）がなければならないことを真実と考えており、それらが何であるかを理解したいと思います。

最も重要なものをほとんど釘付けにしました。いくつかのマイナーな追加と、実際に成功するテストの欠点があります-実際にテストをしたくない場合（以下を参照）。

• 開発時間：テスト駆動開発では、これはすでに単体テストで計算されていますが、統合およびシステムテストが必要であり、自動化コードも必要になる場合があります。一度書かれたコードは通常、後のいくつかの段階でテストされます。

• スキルレベル：もちろん、ツールをサポートする必要があります。しかし、それはあなた自身のチームだけではありません。大規模なプロジェクトでは、チームの製品と他の製品との間のインターフェイスをチェックするためのテストを作成する別のテストチームが存在する場合があります。より多くの人々がより多くの知識を持たなければなりません。

• ツーリングのニーズ：あなたはそこにいます。これに追加することはあまりありません。

• 失敗したテスト：これは本当のバグです（とにかく私にとって）。さまざまな理由がありますが、それぞれがデメリットと見なされます。そして最大の欠点は、これらの理由のどれが実際に失敗したテストに当てはまるかを決定するのに必要な時間です。

  • 実際のバグが原因で失敗しました。（これはもちろん有利なので、完全を期すために）
  • テストコードは従来のバグで記述されているため、失敗しました。
  • テストコードは古いバージョンの製品用に作成されており、互換性がないため、失敗しました
  • 要件が変更され、テストされた動作が「正しい」と見なされるようになったため失敗

• 失敗しないテスト：これらも不利であり、非常に悪い場合があります。あなたが物事を変えて、アダムが答えたものに近づくとき、それは大抵起こります。製品のコードを変更しても、テストでそれがまったく考慮されない場合、この「誤ったセキュリティの感覚」が発生します。

  失敗しないテストの重要な側面は、要件の変更により、以前の動作が無効になる可能性があることです。十分なトレーサビリティがある場合、要件の変更はテストコードと一致する必要があり、そのテストを信頼できなくなっていることがわかります。もちろん、このトレーサビリティを維持することはさらに別の欠点です。そうでない場合と、あなたは失敗しないテストで終わるが、実際にあなたの製品が動作することを検証誤って。道のどこかで、これはあなたに当たります。

• 追加の展開コスト：独自のマシンで開発者として単体テストを実行するだけではありません。自動化されたテストでは、誰かがあなたの作業を中断したときを見つけるために、ある中央の場所で他からのコミットでそれらを実行したいです。これは素晴らしいことですが、セットアップと保守も必要です。

私たちのチームで自動テストを試し始めたばかりですが、私が見た最大の欠点は、自動テストを念頭に置いて設計されていないレガシーコードに適用するのが非常に難しいことです。間違いなく長期的にはコードを改善しますが、正気を保ちながら自動テストに必要なリファクタリングのレベルは、短期間での参入にとって非常に高い障壁です。短期的なコミットメントを満たすための単体テスト。言い換えれば、あなたがすでに技術的な負債に深くかかっているとき、クレジットカードを完済することははるかに難しいです。

おそらく、最も重要な欠点は... テストは製品コードです。作成するすべてのテストは、保守およびサポートが必要なコードベースにコードを追加します。そうしないと、結果が信じられないテストにつながるため、他に選択肢はありません。誤解しないでください-私は自動テストの大擁護者です。しかし、すべてにはコストがかかり、これは大きなものです。

これらが完全に適用可能なデメリットであるとは言いませんが、私が最もヒットしたいくつかは次のとおりです。

• 複雑なエンタープライズアプリケーションでのテストのセットアップにかかった時間。
• 誤って失敗した古いテストの処理、言い換えれば、システムが進化し、現在テストが間違っています。
• 不完全なテストカバレッジまたは未知のテストカバレッジからの誤った信頼。

不完全なテストカバレッジは、誤った安心感につながる可能性があります。リファクタリングを行い、テストを使用してその妥当性を証明する場合、テストでこれを証明できるものは何ですか？

テストの作成にかかる時間は、私たちにとって問題になることがあります。自動テストには、単体テストだけでなく、ユースケーステストも含まれます。これらはより広くなる傾向があり、コンテキストが必要です。

もちろん、私の視点は、単体テストよりも古いアプリケーションからのものです。

彼らの主な問題は、彼らが誤った安心感を提供できることだと思います。ユニットテストがあるからといって、実際に何かを実行しているわけではなく、要件を適切にテストすることも含まれます。

さらに、自動化されたテストにはバグ自体を含めることもできるため、単体テストでテストを行う必要があるかどうかについて疑問が生じるため、必ずしも何も達成できません。

自動化テストには多くの利点がありますが、独自の欠点もあります。欠点のいくつかは次のとおりです。

• 自動化テストスクリプトを作成するには、習熟度が必要です。
• テストスクリプトのデバッグは大きな問題です。テストスクリプトにエラーがある場合、致命的な結果につながる場合があります。
• 再生方法の場合、テストのメンテナンスには費用がかかります。GUIで小さな変更が発生しても、テストスクリプトを再記録するか、新しいテストスクリプトに置き換える必要があります。
• テストスクリプトがより多くの画面をテストする場合、テストデータファイルのメンテナンスは困難です。

上記の欠点のいくつかは、自動化されたスクリプトから得られる利点からしばしば差し引かれます。自動化テストには長所と短所がありますが、世界中で広く採用されています。

私は最近、ゲーム開発のテストについて質問しました。これは、私がこのテストについて知っていた方法です。そこの答えは、いくつかの奇妙で具体的な欠点を示しています。

1. コードを高度に結合する必要がある場合は、コストがかかります。
2. さまざまなハードウェアプラットフォームに注意する必要がある場合、ユーザーへの出力を分析する必要がある場合、コードの結果がより広いコンテキストでのみ意味をなす場合、実行することは困難です。
3. UIとUXのテストは非常に困難です。
4. そして、特に、自動テストは、非常に低コストの（または無料の）ベータテスターの束よりも高価で効果が低い場合があります。

4番目の点は、私の経験を思い出させてくれます。私は非常にスリムでXP指向のスクラム管理会社で働いていましたが、そこでは単体テストが強く推奨されました。しかし、よりスリムで官僚的でないスタイルへの道のりで、同社はQAチームの構築を怠りました。テスターはいませんでした。そのため、テスト範囲が95％を超える場合でも、顧客はいくつかのシステムを使用して些細なバグを頻繁に発見しました。そこで、別のポイントを追加します。

• 自動化されたテストでは、QAとテストは重要ではないと感じることがあります。

また、私は当時、ドキュメンテーションについて考えていましたが、テスト2に（多少は）有効であると思われる仮説を作成しました。コードは非常に急速に進化するので、そのような速度に沿ったドキュメントを作成するのはかなり難しいと感じたため、簡単に古くなった重いドキュメントを書くよりもコードを読みやすくすることに時間を費やす方が価値があります。（もちろん、これは APIには適用されず、内部実装にのみ適用されます。）テストには、同じ問題が少しあります。テストされたコードと比較すると、書くのが遅すぎるかもしれません。OTOH、テストは古いことを警告しているので、ささいな問題ではありませんが、ドキュメントを非常に慎重に読み直さない限り、ドキュメントは静かなままです。

最後に、私が時々見つける問題：自動化されたテストはツールに依存しているかもしれず、それらのツールは不完全に書かれているかもしれません。しばらく前にXULを使用してプロジェクトを開始しましたが、そのようなプラットフォーム用の単体テストを書くのは苦痛です。Objective-C、Cocoa、およびXcode 3を使用して別のアプリケーションを開始しましたが、そのテストモデルは基本的に多くの回避策でした。

自動テストの欠点について他の経験もありますが、それらのほとんどは他の回答に記載されています。それにもかかわらず、私は自動化されたテストの激しい支持者です。これにより、非常に多くの作業と頭痛が軽減され、デフォルトで常にお勧めします。自動テストの利点と比較した場合、これらの欠点は単なる詳細に過ぎないと判断します。（オートダフェを避けるために異端をコメントした後は、常にあなたの信仰を宣言することが重要です。）

言及されていない2つは次のとおりです。

• 大規模なテストスイートの実行にかかる可能性のあるクロック時間の長さ

私は自動化されたQAの取り組みに参加しており、テストが遅いため、テストの実行に半日かかりました。テストの作成に注意を払っていない場合、テストスイートもこのようになる可能性があります。あなたがその時間を管理するまで、これは大したことではないように聞こえます。

• いくつかのテスト作成方法の脆弱性

一部のテスト方法（UIの自動化など）は、向きを変えるたびに壊れているようです。たとえば、スクリプトがボタンの表示を待機しているためにテストプロセスがハングする場合は特に痛いですが、ボタンの名前が変更されています。

これらは両方とも回避できるものであり、適切なテストプラクティスがあります。テストスイートを高速に保つ方法を見つけます（マシン/ CPUにテスト実行を分散するなどのトリックを行う必要がある場合でも）。同様に、テストを記述する脆弱な方法を避けるように注意することができます。

もう1つ付け加えたいのは、誤った安心感です。

非常に小さく明確に定義された問題セットを超えて、包括的なテストを作成することはできません。私たちのソフトウェアには、自動化されたテストでは単純にテストされないバグが存在する場合があります。自動化されたテストに合格すると、コードにバグがないと思い込むことがよくあります。

経営/ベンチャー資本家を説得するのは難しい

• テスト自動化により、初期費用が増加します。
• テスト自動化により、市場投入までの時間が増加します。
• テスト自動化の利点は、中期およびログ期間にあります。激しい競争は、短期的な利益により重点を置いています。

詳細については、市場主導型ユニットテストをご覧ください。

主な欠点の1つは、自己学習テストを使用することで克服できます。この状況では、期待される結果はすべてデータとして保存され、自己学習モードのテストスイートユーザーによる最小限のレビューで更新可能です（古い期待される結果と新しい実際の結果の差分を表示-yを押すと更新が期待されます）。このテストスイートの学習モードは注意して使用する必要があるため、バグのある動作は許容できるものとして学習されません。