回答。

複雑なアプリケーションのビジネスロジックの自動テストは、バリデーターをチェックする最初のスクリプトから、現代のマイクロサービステストに至るまで長い歴史があります。アーキテクチャが複雑化するにつれて（モノリス、SOA、マイクロおよびマクロサービス）、アーキテクチャのあるレベルでの変更が他のレベルのテストを壊す問題が浮上しました。

問題点は、アプリケーションの層間の相互作用、契約の変更、データ構造の変更、ビジネスプロセスの再編成に対して安定したテストを書く必要があることです。テストが実装の詳細に固定されることが多く、テストが「脆弱」でメンテナンスが難しくなってしまいます。

解決策は、入力/出力データに焦点を当てた「ブラックボックス」テストの原則に従い、システムのエンティティにアクセスするために抽象化層を使用することです（例えば、アーキテクチャにおけるサービス層とドメイン層など）。ビジネスロジックをインフラストラクチャの詳細から切り離し、外部依存関係に対してモック/スタブを使用してテストの隔離と安定性を確保する必要があります。

主な特徴：

契約のテストに重点を置き、内部実装に依存せずビジネスインバリアントを検証する。
ロジックへのアクセスに抽象化層を使用する（例：アプリケーションサービス→ドメインサービス→リポジトリ）。
テスト環境の再現性と隔離のためにmvp/mocks/stubsを導入する。

注意すべき質問。

UI層を介したビジネスロジックの検証とAPI/ドメイン層を介した検証の違いは何ですか？

UIテストは変更に対して一般的に脆弱であり、インターフェースのわずかな変更がテストの失敗に繋がることがある。APIやドメイン層を介したテストは、フロントエンドへの依存が少なく、ビジネスルールの検証をより成功裏に隔離することができる。

ビジネスロジックのテストのためにすべての依存関係をモックする必要がありますか？

いいえ！テスト環境で実現できるもの（例えば、軽量なメモリをデータベースの代わりに使用する）をモックする必要はありません。モックは、複雑または高価な外部依存関係のために必要です。完全なモッキングは、実際のシナリオを反映していない「フェイク」テストを引き起こす可能性があります。

ビジネスロジックのためにポジティブシナリオだけをテストするのでは不十分ですか？

いいえ！すべてのコーナーケースとネガティブシナリオをカバーすることが重要です。そうしないと、重大なバグが見逃され、主なビジネスプロセスが脆弱になってしまいます。

一般的なエラーとアンチパターン

テストが内部オブジェクト/構造に依存していること、脆弱なセレクター。
ネガティブ/代替パスがない。
小さな変異を持つ多数の重複テスト。

実生活の例

ネガティブケース

プロジェクトではビジネスロジックがUI Seleniumテストを介してのみテストされ、ボタンやフォームに直接取り組んでいました。フロントエンドのリファクタリングのたびに、自動テストが大量に失敗してしまいました。

利点:

全機能の迅速な初期カバレッジ
シナリオの本質を管理者に簡単に説明できる

欠点:

脆弱性：UIのわずかな変更が全てを壊す
遅く、不安定なテストで、メンテナンスが複雑

ポジティブケース

プロジェクトにはAPIおよびユニットテストの中間層が実装されていました。UIは重要なパスのみをカバーし、残りのすべてのバリデーションはコストのかかるサービスのモックを用いてサービス層を介して行われました。