回答。

問題の経緯:

最初は、自動テストが「そのまま」書かれ、アーキテクチャの分割がない状態で、検証ロジックと実行メカニズムが混在していました。プロジェクトの成長に伴い、フレームワークとテストロジックを混在させることが脆弱で保守が難しいコードベースを生み出すことが明らかになりました。そのため、責任分担に関するアーキテクチャの推奨事項が登場しました。

問題:

テストがフレームワークの内部実装に依存したり、環境との相互作用に関するロジックが含まれると、変更があるたびに多くのテストを再作成する必要があります。テストケースは複雑で、コードが重複し、新しいフレームワークやプラットフォームへの移行が難しくなります。

解決策:

厳密に分割する:

フレームワーク (基盤インフラストラクチャ): テストの実行に関する一般的なメカニズム、ログ記録、エラー処理、レポート、補助クラス（例えば、ドライバ、アダプタ、ユーティリティ）の基盤。
テストロジック (テストケース): テストの意味的な目的を表現する具体的なシナリオで、フレームワークの公開APIのみを使用します。

重要な特徴:

プラットフォームの変更による保守の容易さ
テストロジックの再利用の可能性
コードの冗長性と重複の削減

意地悪な質問。

テストが少ない場合、テスト内で直接テストステップを書くことはできますか？

しない方が良いです。短いテストでもすぐに成長する可能性があり、層がないと混乱を引き起こします。

テストシナリオは実行メカニズムを知る必要がありますか（例: ドライバを初期化するタイミングなど）？

いいえ。インフラのすべての詳細はフレームワークの層に隠されるべきです。

テストケース内にテストパラメータをハードコーディングすることは許可されますか（例: URL、認証情報）？

いいえ。テストパラメータはフレームワークと環境の設定を通じて構成する必要があります。

一般的な間違いとアンチパターン

フレームワークのメソッド内に状態の検証を置く
テストでフレームワークのプライベートメソッドを使用する
テストで補助関数を重複させる
パラメータをハードコーディングする

実生活の例

ネガティブケース

プロジェクトではテストが直接Seleniumドライバのメソッドを呼び出し、各テストでWebDriverへの接続を繰り返す。各テストが独自に設定を解析します。

長所:

アーキテクチャなしで自動テストをすぐに書き始めることができる。

短所:

ドライバや実行パラメータの変更が大規模な修正につながる。
すべてのテストで重複するコード。
プロジェクトのスケーリングと保守が難しい。

ポジティブケース

テストはフレームワークの基本的な抽象を利用します: 一般的な初期化とteardown、設定を通じたパラメータの透過的な受け渡し、テストロジックは高レベルのメソッドを通じて表現されます。