マイナーな変更または表面的な変更のために失敗しないSelenium（または類似の）のテストをどのように作成できますか？

私は先週かそこらを費やして、セレンを学び、これから立ち上げるWebサイトの一連のWebテストを作成しました。学ぶのは素晴らしく、私はいくつかのxpathとcssのロケーションテクニックを取り上げました。

私にとっての問題は、小さな変更がテストを壊すのを見ていることです-div、id、またはウィジェットを識別するのに役立ついくつかのautoid番号を変更すると、多くのテストを壊します-それは非常に壊れやすいようです。

セレン（または他の同様の）テストを作成しましたか？テストの脆弱な性質にどのように対処しますか（またはテストを脆弱にするのを止めるには）、どのような種類のテストにセレンを使用しますか？

Seleniumの目的は、UI駆動型の統合テストを作成することです。

統合テストは、システムのすべてのコンポーネントが一緒に展開されたときに正しく機能することを確認します。統合テストは十分なテスト戦略ではなく、ユニットテストや受け入れテストなど、異なる焦点を持つ他のテスト戦略を補完します。

UI駆動のテストは本質的に脆弱ですが、SeleniumとWatirは、記録と再生ツールの初期の段階からのステップアップです。この問題に対処する方法はいくつかあります-以下は、世界クラスの専門家からのアドバイスをまとめたものです。

このタイプのテストからすべてのテストカバレッジを取得しようとしないでください。Robert C. Martin は、統合テストによるコードカバレッジは約20％になるはずだと主張しています。入力がいくつかのアプリケーション層から離れている場合、実行のすべてのパスをテストすることは単に非現実的です。

単体テストと受け入れテストからほとんどのテストカバレッジを取得します。FinnNkの回答でGojko Adzicの記事へのリンクを探してください。Adzicは、受け入れテストとUIのバイパスによるビジネスロジックのテストについて繰り返し議論しました。

ただし、UI駆動テストの一部を作成する必要があります。ここで、「UIを介してビジネスロジックをテストしないでください」に加えて、実用的なアドバイスが必要になります。出発点として、Patrick Wilson-Welshのブログをお勧めします。

些細な数値を超えてこのようなテストを作成する場合に最も重要なことは、対称的な変更の考え方です。コードの小さな変更により、テストスイートに小さな変更が生じるはずです。

たとえば、100回のテストで2つのテキストボックスを使用して誰かの名前を収集するとします。これらのテストをきちんと書いた場合（またはレコード再生を使用している場合）、変更するテストは100個あります。代わりに「名前を入力する」ステップを抽象化し、直接セレンを使用する代わりにテストでそれを使用する場合、変更を行う場所は1つしかありません。使用する抽象化のレイヤーの数はコンテキストに依存しますが、抽象化を使用すると、テストを保守しやすくするために役立ちます。

2番目に重要なことは、セレクターが最も重要で変更される可能性が最も低いものに基づいていることを確認することです。場合によっては、これはIDまたはクラスになることもあれば、要素内または要素を囲むテキストになることもあります。常に最も単純なセレクター（例：id）を優先しますが、これを実現するには、xpathのようなものを使用する必要があります。

Gojko Adzicは彼のブログでこの種のテストに関してたくさんの素晴らしいアドバイスをしています-彼のSine of Deathと特にそれを避ける方法をチェックしてください。

テストにより、コードが期待どおりに動作することを確認します。テストが定期的に失敗する場合、テストは正しいことをテストしていないか、開発者がテストを気にしていません。

個人的には、<div>タグの存在がテストに違反する場合、テストは不必要に周囲のタグに厳密に依存していると思います。より寛大なアプローチを取る必要があります。