私はユニットテストに慣れていないので、もう少し手がかりのある人の意見を聞きたいと思います。
すぐにスクリーンスクレイピングコードを書く必要があります。ターゲットシステムは、大量のHTML解析と同様の揮発性の良さが含まれるWebUIです。ターゲットシステムから変更が通知されることはありません（たとえば、サイトに再設計を加えたり、機能を変更したりします）。ですから、暗号解読は定期的に行われると思います。
ですから、私の本当の質問は、ユニットテストのどれだけがインターフェース（私がスクレイピングしているWebサイト）の変更について心配したり対処したりする必要があるかということだと思います。
単体テストかどうかは別として、消費しているデータが元の状態であることを確認する必要があるため、実行時に徹底的にテストする必要があります。すべての実行の前に単体テストを実行した場合でも、WebUIはテストと実行時の間で変更される可能性があります。
では、コード内テストと例外処理に焦点を合わせますか？それは、砂に線を引き、この種のテストを単体テストから完全に除外することを意味しますか？
ありがとう
単体テストは常に、再現可能な既知の結果が得られるように設計する必要があります。
したがって、スクリーン スクレーパーの単体テストを行うには、既知の HTML セットに対してテストを作成する必要があります (これを表すためにモック オブジェクトを使用できます)。
あなたが話しているようなことは、私には単体テストのシナリオのようには聞こえません。コードが可能な限り確実に実行されるようにしたい場合は、コード内テストについての話です。そして例外処理。
また、警告コードをいくつか含めて、HTML が期待どおりに解析されない場合にシステムが認識できるようにします。
できるだけテストを分離するようにしてください。実際のコードを実行する低レベルのテストでデータ処理をテストします (つまり、シミュレートされたブラウザーを使用しない)。
シミュレートされたブラウザーでは、ボタンをクリックしたとき、フォームを送信したとき、リンクをたどったときに正しいことが起こることを確認してください。
レイアウトが正しいかどうかをテストしようとしないでください。
ここで単体テストが役立つと思うのは、ビルド サーバーがある場合、コードが機能しなくなったことを早期に警告することです。サイトが HTML を変更してもスクリーンスクレイピングが引き続き機能することを証明する単体テストを作成することはできません (変更内容がわからないため)。
単体テストを作成して、自分の努力から何か有用なものが返されることを確認できる場合があります。