![HTTP 接続を使用したユニット テスト コードの DNS ハッキングは可能でしょうか、それとも理にかなっていますか?](https://rvso.com/image/1692554/HTTP%20%E6%8E%A5%E7%B6%9A%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%9F%E3%83%A6%E3%83%8B%E3%83%83%E3%83%88%20%E3%83%86%E3%82%B9%E3%83%88%20%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AE%20DNS%20%E3%83%8F%E3%83%83%E3%82%AD%E3%83%B3%E3%82%B0%E3%81%AF%E5%8F%AF%E8%83%BD%E3%81%A7%E3%81%97%E3%82%87%E3%81%86%E3%81%8B%E3%80%81%E3%81%9D%E3%82%8C%E3%81%A8%E3%82%82%E7%90%86%E3%81%AB%E3%81%8B%E3%81%AA%E3%81%A3%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%81%8B%3F.png)
ローカル テスト サーバーを使用して、発信 HTTP 接続を模擬するために、限定された方法で DNS をハイジャックする賢明な方法はありますか?
アイデアとしては、コードは通常と同じように実行されますが、リクエストはローカル テスト サーバーにリダイレクトされ、代わりに模擬応答が返されます。
要求された URI が localhost になるように一連のテスト構成を用意することでこれを実現できることはわかっていますが、これによってさまざまな問題が発生します。最も一般的な問題は、開発者が本番構成のコメントを解除するのを忘れたり、テスト構成の設定について混乱したりすることです。
答え1
チェックするコードに触れないのは賢明です。したがって、テスト サーバーの使用を強制するために環境を操作するのは正しいことです。
DNS ハッキングはネットワーク全体に影響を及ぼし、同じサービスを対象とした他のテストに支障をきたす可能性があります。
影響を最小限に抑えるには、ネットワークトラフィックをテストサーバーに再ルーティングする最も簡単な方法は、hosts
ファイルを構成することです。クライアント側テストするソフトウェアがインストールされている場所。
# Linux:
/etc/hosts
# Windows:
%SystemRoot%\System32\drivers\etc\hosts
テスト システムの IP を運用サーバーの DNS 名にマップするだけです。
# IP of the test server:
192.168.10.20 prod.server.com prod2.server.com
192.168.10.20 prod prod2 # if prod-servers are part of the local network.
サーバー名を解決するために、システムはまずhosts
ファイルをチェックします。その後、成功しなかった場合は DNS 要求に従います。
再構成後に DNS キャッシュをクリアすることをお勧めします。
# Linux:
resolvectl flush-caches
# Windows:
ipconfig /flushdns
この場合 (または任意の DNS ソリューションの場合)、ソフトウェアが実稼働サーバーの IP アドレスをどこにもコード化していないことを確認する必要があります。 (おそらく、テスト ネットワークをインターネット/実稼働ネットワークから切断しますか?)