Answer.

When working with automated tests, the right structure is the key to their effectiveness and viability.

Background

Previously, automated tests were often created as monolithic and tightly coupled scripts. This made them difficult to maintain and extend. The increase in the number of tests highlighted the importance of a proper architecture.

Problem

Without a clear structure, issues arise:

code duplication
difficulties in maintaining changes in requirements
low readability and high likelihood of errors

Solution

Use clear levels of abstraction for your tests:

Test scenarios should invoke already implemented steps and business methods, not implementation details.
Business level encapsulates user actions (e.g., "create order"), without revealing technical details.
Technical level (e.g., Page Object) works with UI elements or APIs.

A good practice is to use:

# Example structure
/tests
  /features
    test_order_creation.py
  /steps
    order_steps.py
  /pages
    order_page.py

Key features:

Clear separation of responsibilities (by layers, modules)
Maximum code reusability
Ease of making changes (just change one entity)

Tricky questions.

What is better: to write long end-to-end tests or short unit tests?

Often, only end-to-end tests are chosen, but it is important to combine different types of tests depending on the goals: all levels (Unit, API, UI) are important for quality checking.

Can both text and locator checks be used in tests simultaneously?

This is not always correct: while both methods can be used at the same time, it should only be justified by the variability of the UI and the logic of the test. It is often excessive and complicates maintenance.

Should the structure of the tested software be fully copied when creating automated tests?

No, the structure of automated tests should be oriented towards ease of testing, rather than exact duplication of the application architecture.

Common mistakes and anti-patterns

Hardcoding test data directly in tests
Copying the same actions in every test
"All in one" scripts: a test executing multiple scenarios at once

Real-life example

Negative case

In one team, automated tests were written by one person, tests were in one file, each test copied steps from the previous one. When the interface was updated, the bug was fixed manually in all tests.

Pros:

Quick writing of basic tests

Cons:

Changing business logic required a complete overhaul of all tests, often with errors

Positive case

In another team, an architectural pattern (separating steps, pages, tests) was introduced. New employees quickly understood and implemented new tests, updates were made in one place.