UI を介したテストまたはビジネス レイヤーに直接アクセスするテストは、長所と短所が異なる 2 つの異なるタイプのテストと見なすことができます。
UI を直接テストしている場合は、ユーザーに表示されるものをテストしていることになり、テストできるようにするためにコードを変更する必要はありません。ただし、まれなケース、またはシステムが例外的な条件 (例外など) にどのように反応するかをテストすることは非常に困難になります。ロバート・マーティンが言うように、もろいのです。インターフェイスが変更された場合は、テストを変更する必要があります。したがって、UI を使用したテストは、UI の成熟度によって異なります。プロジェクトの後半では、UI はより安定しているため、UI を介してテストすることはより理にかなっています。また、UI を介していくつかのものをテストすることは、困難または複雑です。
ビジネス層をテストしている場合は、コーナー条件をより簡単にテストでき、UI の変更の影響を受けにくくなります。ただし、おっしゃる通り、この種のテストができるようにソフトウェアを作成する必要があります。それを許可するために新しいインターフェースを公開する必要があるかもしれませんが、それを維持する必要があります。私の経験では、開発者にこの種のインターフェースをサポートしてもらうのは非常に難しい場合があります。実際のインターフェースほど重要ではないと考えられています。しかし、それは常に可能です。この種のインターフェースは開発者からの同意が必要です。そうしないと、時間の経過とともに「サポートされなくなる」リスクがあります。
外部インターフェイスがない場合は、それを求めてみてください。それが良い考えだと彼らを説得できるかもしれません。プロジェクトの開始時の方が簡単です。
外部インターフェイスがある場合は、それを使用してビジネス ロジックをテストします。
それ以外の場合は、UI を使用してこれらをテストする必要があります。1 つの方法として、UI を使用してスモーク テストを行い、次の質問に答えることができます。このソフトウェアはテスト可能ですか? 開発者からビルドを取得するたびにテストする必要がある一般的なことを考えてください。ログインできますか、ログアウトできますか、メインページは表示されますか、簡単な注文はできますか? これらのうち 5 つまたは 6 つを選択し、これらをテストするための自動テスト スイートを構築します。これらのテストは、UI を介して実際にテストできる機能の量と、その有用性に関するガイドとして使用してください。
その後、開発者のところに行って外部インターフェースを要求するときに、これを引数として使用できます。
