回答。

外部サービスとのテストの分離性は、信頼性のある自動化に不可欠な条件です。

問題の背景: 初期の自動化システムでは、外部APIやデータベースに頻繁に「遭遇」し、それらはしばしばアクセスできなかったり、予期しないデータを返したりしました。テストの分離がなければ、結果を再現することはできません：フリッカー、外部の問題によるクラッシュ、偶発的な失敗。

問題:

外部サービスはしばしば不安定です：契約が変更される可能性があり、データがないか、テストが副作用を引き起こす可能性があります。
予測可能な結果のために外部応答を（「固定」して）制御する必要があります。
遅い応答とローカルまたはCIでのシナリオの再現が不可能です。

解決策:

外部APIの応答をシミュレートするためのローカルスタブである「モック」や「スタブ」の使用。WireMock（Java）、httpmock（Python）、MockServer、TestContainersが一般的です。
インメモリソリューションや各テストの前後でクリアされ、再度入力されるフィクスチャを使用してデータベースをエミュレートします。

テストデータのIDを変数に抽出し、テストが並行して実行でき、お互いに「踏み荒らす」ことがないようにします。

import requests
BASE_URL = "http://localhost:1080/api"
def test_order_creation():
    mock_response = {"orderId": 12345, "state": "created"}
    # 実際のテストでは、応答はモックサーバーが返します
    # ここでrequests.postを呼び出し、assert ...

主な特徴:

外部依存性を模倣するためのモックサーバーの使用。
ステートのクリーンさ：テストの前後でのデータのクリア（セットアップ/テアダウン）。
テストエンティティの識別子の分離。

トリッキーな質問。

毎回実際のサービスを通して統合テストを実施する必要がありますか？

いいえ。定期的にモックやスタブを使用し、統合テストは別で、頻繁にではなく、管理の下で実行します。

実際の外部APIを使用したテストが常により信頼できる結果を提供しますか？

いいえ。逆に、それらはあまり安定せず、パートナー側の変更によってクラッシュすることがあります。継続的なフリックテストはパイプラインの品質を悪化させます。

外部サービスを使用する並行自動テストに同じテストデータを使用できますか？

いいえ。これは衝突、「レース」や不安定性を引き起こす可能性があります。識別子とステートはテスト/スレッドごとにユニークである必要があります。

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

テストデータのクリアや分離がない。
単体テストでさえ実際のAPIを使用する。
不当なタイムアウトの短縮が、偽の失敗を引き起こす。
サードパーティのAPIの変更を考慮しない（すべてのテストが壊れる）。

実生活の例

ネガティブケース

会社は速度のためにすべての自動テストを実際のサードパーティAPI（決済ゲートウェイ）で実行することに決めました。テストが何度もブロックされ、制限がかかり、アクセスの復元が必要になり、データが「流出」し、偽のトリガーが発生しました。

利点:

実際のサービスとの迅速な統合。

欠点:

オペレーター側の変更がテストを壊し、時間とコストを無駄にし、テストのゴミが「生産」サービスに、再現の難しさが発生しました。

ポジティブケース

MockServerと架空のインメモリデータベースを設定しました。各テストの前にステートをリセットし、データはユニークです。実際の統合テストは別で、頻繁ではありませんでした。