Answer.

Isolation of tests with external services is a mandatory condition for reliable automation.

Background: Early automation systems "struggled" with external APIs and databases that were often either unavailable or returned unexpected data. Without isolation of automated tests, it is impossible to reproduce the result: flakiness, failures due to external issues, and random crashes.

Problem:

External services are often unstable: they can change the contract, data may be unavailable, or the test may cause side effects.
The need to control ("fix") the external response for result predictability.
Slow responses and the inability to reproduce scenarios locally or in CI.

Solution:

Use of "mocks" and "stubs" — local placeholders that simulate responses from external APIs. Popular ones include WireMock (Java), httpmock (Python), MockServer, TestContainers.
Emulation of a database using in-memory solutions or fixtures that are cleaned and repopulated before each test.

Moving test data IDs to variables so that tests can run in parallel without "overlapping" each other.

import requests
BASE_URL = "http://localhost:1080/api"
def test_order_creation():
    mock_response = {"orderId": 12345, "state": "created"}
    # In actual tests, the response would be returned by the mock server
    # Here, the requests.post call and assert ...

Key features:

Use of mock servers to simulate third-party dependencies.
Clean state: clearing data before/after the test (setup/teardown).
Isolation of test entity identifiers.

Trick questions.

Is it necessary to conduct integration tests through real services on every run?

No. Mocks/stubs can be used regularly, while integration tests can be run separately, less frequently, and under control.

Will tests with real external APIs always yield more reliable results?

No. On the contrary, they are less stable and may fail due to changes on the partner's side. Constant flaky tests degrade the quality of the pipeline.

Can the same test data be used for parallel automated tests with external services?

No. This may lead to collisions, "races," and instability. Identifiers and state must be unique for each test/thread.

Common mistakes and anti-patterns

No clearing or isolating of test data.
Using the real API even for unit tests.
Unjustified shortening of timeout periods, leading to false failures.
Ignoring changes in the external API (breaking tests for everyone at once).

Real-life example

Negative case

The company decided to run all automated tests on real third-party APIs (payment gateway) for speed. Several times, tests were banned, limits were hit, access had to be restored, data "leaked" into real reports, and false positives emerged.

Pros:

Quick integration with a real service.

Cons:

Changes on the operator's side broke tests, wasting time and money, test debris in "production" services, difficulty in reproduction.

Positive case

Set up MockServer and a dummy in-memory database. Before each test, the state was reset, and data was unique. Real integration tests were run separately and less frequently.