Setups, Teardowns, Tags, Timeouts, and Suite Lifecycle: Configuration, Design Patterns, and Trade-Offs

1. Suite-scoped fixture versus per-test isolation

2. The scope rule: choose the narrowest owner that is still correct

Do not promote state to suite scope merely because setup is expensive. Shared mutable resources couple tests and make parallel execution unsafe. A suite-level fixture is strongest when it is immutable after setup or when the entire suite intentionally models one shared workflow. Per-test state should remain the default when tests can independently create it.

3. Default fixtures versus explicit overrides

Test Setup/Test Teardown in Settings define defaults. A test can override them with [Setup]/[Teardown], and an empty setting disables the default. That power should be visible in code review because one test that silently disables cleanup can contaminate later cases.

*** Settings ***
Test Setup       Prepare Case
Test Teardown    Cleanup Case

*** Test Cases ***
Uses Defaults
    Verify Something

Different Setup
    [Setup]    Prepare Special Case
    Verify Something

No Teardown Teaching Example
    [Teardown]
    Log    Disables the default teardown -- use only deliberately

4. Teardown strictness versus primary failure

Two bad extremes are common. A teardown that ignores every error can leave dirty state while reporting a clean cleanup path. A teardown that performs many brittle assertions can generate secondary failures that distract from the original defect.

A safer production pattern is:

1. preserve first-failure evidence;
2. attempt cleanup using resource identifiers owned by the current test;
3. verify the important postcondition (for example, the owned directory no longer exists);
4. report cleanup failure clearly without deleting or rewriting the original evidence.

5. Test timeout versus user-keyword timeout

6. Timeouts are budgets, not readiness checks

If the business requirement is “wait until service becomes healthy,” encode an observable condition with a bounded polling mechanism in the appropriate library layer. A giant test timeout only says how long Robot will tolerate the entire case. It does not explain what condition is awaited and may interrupt execution at an arbitrary point.

7. Static tags, runtime tags, and configuration

Static tags are best for durable classification such as smoke, contract, owner-payments, or requires-local-fixture. Runtime tags can record an observation discovered during execution, such as feature-flag-on, but they should not be used to decide the current test’s environment after selection.

Environment values belong in variables or future execution profiles/argument files. Tags may describe an environment requirement; they should not be the environment itself.

8. Prefer Test Tags over legacy Force Tags/Default Tags

Test Tags is the modern suite-level setting. If one test should remove a common tag, [Tags] -tag supports removal. Legacy Force Tags and Default Tags still work in 7.4.2 but are deprecated and should not be the basis of new course content.

9. Worked decision table

10. Parallel-safety preview

Pabot arrives later in the course, but lifecycle design must prepare for it now. Shared filenames, shared accounts, fixed ports, and mutable suite-level objects are future parallel collisions. Use run/test identifiers and narrow ownership even when today’s execution is serial.

11. Knowledge check

12. Summary and next step

Good lifecycle configuration is mostly about ownership: narrow mutable fixtures, explicit defaults and overrides, condition-specific waits, bounded timeouts, durable classification tags, and cleanup that preserves evidence. Lesson 4 applies that design model to realistic failures—shared-state leakage, teardown noise, overbroad timeouts, order dependence, and unsafe cleanup.

Further reading

• Robot Framework 7.4.2 User Guide — test setup and teardown — defaults, overrides, teardown guarantees, and task aliases.
• Robot Framework 7.4.2 User Guide — execution flow — suite/test/keyword setup and teardown ordering and failure semantics.
• Robot Framework 7.4.2 User Guide — timeouts — test versus user-keyword timeout behavior and safety cautions.
• Robot Framework 7.4.2 User Guide — tags — Test Tags, reserved tags, include/exclude/skip semantics, and deprecations.
• Robot Framework 7.4.2 BuiltIn — Set Tags, Remove Tags, Skip/Skip If, and status/control helpers.
• Robot Framework on PyPI — current stable/pre-release stream and Python requirement.