Setups, Teardowns, Tags, Timeouts, and Suite Lifecycle: Core Concepts and Mental Model

1. The practical problem: cleanup must survive abnormal paths

Chapter 08 introduced owned side effects: temporary directories, files, child processes, transformed data, and evidence. Chapter 09 answers the next operational question: who creates those resources, who verifies them, and who cleans them when something fails or times out?

A reliable suite cannot depend on the happy path reaching its last keyword. Lifecycle hooks exist so preparation and cleanup have explicit ownership. Tags and timeouts influence what runs and how long it may run, but neither replaces cleanup design.

2. Four lifecycle levels, four ownership questions

3. Test and task lifecycle settings are aliases, not different engines

When the file contains tasks rather than tests, Task Setup, Task Teardown, Task Tags, and Task Timeout are aliases for the corresponding Test settings. The execution semantics are the same; the terminology communicates automation intent. One file still contains either tests or tasks, not both.

4. A setup or teardown is one keyword call

Robot Framework settings such as Suite Setup, Test Setup, [Setup], and [Teardown] name one keyword plus arguments. If several actions belong together, create a higher-level user keyword whose name explains the contract. This keeps the lifecycle setting readable and the individual steps visible in log.html.

*** Settings ***
Test Setup       Prepare Isolated Workspace
Test Teardown    Collect Evidence And Cleanup

*** Keywords ***
Prepare Isolated Workspace
    Create Directory    ${WORKSPACE}
    File Should Exist    ${FIXTURE}

Collect Evidence And Cleanup
    Capture Safe Evidence
    Remove Owned Workspace

5. Failure does not mean “nothing else runs”

Normal test execution stops at the first non-continuable failure. Teardown is different: Robot Framework enables continue-on-failure through teardown levels so cleanup steps are attempted even if an earlier teardown step fails. That is useful, but it creates a design obligation: cleanup steps should be independently safe and should not assume the previous teardown step succeeded.

6. Timeout is a safety fuse, not synchronization

Robot Framework supports test/task timeouts and user-keyword timeouts. A test timeout stops the currently executing keyword when the remaining test budget expires, fails the test, and then allows test teardown to run without the test timeout interrupting it. A user-keyword timeout applies to that keyword—including when the keyword is used in teardown—so it can bound a cleanup helper that might otherwise hang.

Timeouts forcibly interrupt execution and may leave a library or external system in an unstable state. Prefer domain-specific bounded waits and library-level timeouts. Use Robot Framework timeout only when there is no safer control.

7. Tags classify and select; they do not isolate state

Normal tags are free-text metadata used in source, logs, reports, statistics, and command-line selection. Test Tags adds common tags to a suite; [Tags] adds or removes tags on an individual test; BuiltIn Set Tags/Remove Tags can modify the current test’s tags at runtime.

Selection happens before the test body executes. A tag added dynamically can appear in results, but it cannot retroactively cause the current test to have been selected. Environment URLs, credentials, ports, and account identities belong in configuration variables—not tags.

8. Reserved robot:* tags are execution controls (lifecycle-relevant subset)

9. Final status is a lifecycle result, not only a body result

A test passes only when the executed test path has no failures. A setup failure can fail a test before its body runs; a teardown failure can fail a test after a successful body. Suite teardown can retroactively fail tests in that suite. The report therefore represents the complete lifecycle contract, not just assertions inside the body.

10. Why this matters in DevOps

CI reruns, parallel workers, and failure triage all assume each test owns a deterministic lifecycle. When setup allocates unique state, teardown preserves first-failure evidence and cleans only owned resources, and tags describe intent instead of hiding configuration, the resulting output.xml becomes trustworthy operational evidence.

11. Knowledge check

12. Summary and next step

You now have the lifecycle mental model: setup prepares owned state, the body exercises intent, teardown preserves evidence and cleans up, suite teardown handles genuinely shared suite resources, tags classify/select, and timeout is a bounded emergency stop. Lesson 2 turns this model into an instrumented local suite whose marker file proves the exact order under PASS, FAIL, and TIMEOUT paths.

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.