Answer.

Historically, when automating the testing of complex processes involving multiple components (UI, API, databases, third-party services), testers faced challenges such as logic duplication, lack of test cohesion, and inability to reproduce end-to-end product usage scenarios.

The problem is that such tests often extend beyond a single subsystem, require complex data preparation, environment setup, and the correct sequence of interactions between various parts of the system. All of this greatly complicates the running, repeatability, and maintenance of automated tests.

The solution is to apply end-to-end automation and to separate state preparation into distinct layers, using test-helpers and hybrid approaches (for example, preparing data through direct database access or via API, and performing checks through the UI). This helps keep the complexity under control without "cluttering" the tests with unnecessary logic. This approach is well-structured according to patterns.

Example:

# Prepare data through API
def create_order():
    ...
# Check result through UI
def test_order_flow():
    id = create_order()
    go_to_order_page(id)
    assert get_status_from_ui() == 'COMPLETED'

Key features:

Multi-level data preparation and validation.
Clear separation of responsibilities for each test (API, UI, database).
Use of mocks or stubs for external dependencies.

Tricky questions.

Can we rely solely on UI tests to check end-to-end processes?

Solely UI tests are not reliable enough, too slow, and often do not allow for a complete verification of complex scenarios with large amounts of data and various states.

How to deal with unstable external services during E2E testing?

Use mocks and stub files to minimize the impact of failures and service unavailability on the stability of E2E tests.

Is it necessary to cover negative cases at each level of complex processes?

Yes, otherwise you might miss integration errors between layers.

Common mistakes and anti-patterns

"Thick" tests that do too much in a single run.
Confusing data preparation within the test (violating the separation of concerns principle).
Lack of data isolation between tests.

Real-life example

Negative case

On a new project, testers began creating end-to-end tests, fully emulating user actions through the UI, but did not consider data preparation and environment stability — tests sometimes failed if external services were unavailable or had changed.

Pros:

Very close to the user scenario.
Easy to demonstrate to the business.

Cons:

Difficulty in maintenance.
Falling stability (dependency on external services).
Difficult debugging.

Positive case

In a similar situation, the tests were divided into data preparation (through API), checking business logic through the UI, and isolating external dependencies through mocks. This significantly increased the speed, stability, and clarity of testing.