回答。

自動テストを扱う際には、正しい構造がその効果と持続可能性の鍵となります。

問題の歴史

以前は、自動テストがモノリシックで密接に関連したスクリプトとして作成されることがよくありました。これにより、保守や拡張が難しくなっていました。テストの数が増えるにつれて、適切なアーキテクチャの重要性が明らかになりました。

問題

明確な構造がないと、以下のような問題が発生します：

• コードの重複
• 要件変更時の保守の困難
• 読みやすさが低く、エラーの可能性が高い

解決策

テストには明確な抽象化レベルを使用してください：

• テストシナリオは、実装されたステップやビジネスメソッドを呼び出すべきであり、実装の詳細を開示するべきではありません。
• ビジネスレベルは、ユーザーアクション（例："注文を作成する"）をカプセル化し、技術的な詳細を明らかにしません。
• 技術レベル（例：ページオブジェクト）は、UI要素やAPIと連携します。

良い実践として、次のような構造を使用することが推奨されます：

# 構造の例
/tests
  /features
    test_order_creation.py
  /steps
    order_steps.py
  /pages
    order_page.py

主な特徴：

• 明確な責任の分担（層、モジュール）
• コードの最大限の再利用性
• 変更の容易さ（1つのエンティティを変更するだけで済む）

トリックの質問。

長いエンドツーエンドテストを書くのが良いか、短いモジュールテストを書くのが良いか？

多くの場合、エンドツーエンドのみを選択しますが、目標に応じて異なる種類のテスト（ユニット、API、UI）を組み合わせることが重要です。

テストでUIをテキストとロケーターの両方で確認できますか？

必ずしも正しいわけではありません：両方の方法を同時に使用することは可能ですが、UIの変更やテストのロジックがそれを正当化する場合に限ります。しばしば過剰で保守が複雑になります。

自動テストを作成する際に、テスト対象のソフトウェアシステムの構造を完全にコピーすべきですか？

いいえ、自動テストの構造はテストのしやすさに焦点を当てるべきであり、アプリケーションのアーキテクチャを正確に複製するべきではありません。

典型的なエラーとアンチパターン

• テストデータをテスト内にハードコーディングする
• 各テストで同じアクションをコピーする
• "すべてを1つに"というスクリプト：テストが多くのシナリオを同時に実行する

実生活の例

ネガティブケース

あるチームでは、自動テストを1人の人間が書き、テストは1つのファイルにあり、それぞれのテストが前のステップをコピーしていました。インターフェースの更新時には、すべてのテストでバグを手動で修正していました。

長所：

• 基本的なテストが迅速に作成できる

短所：

• ビジネスロジックの変更は、すべてのテストを必然的に再設計する必要があり、しばしばエラーが発生しました。

ポジティブケース

別のチームでは、アーキテクチャテンプレートを導入しました（ステップ、ページ、テストの分離）。新しい社員はすぐに理解し、新しいテストを迅速に導入し、更新は1か所で行われました。

長所：

• 保守が容易で、自動テストの拡張が迅速
• 新しい社員の迅速な適応

短所：

• 初期段階では構造デザインに時間を費やしました。