BuiltIn Library and Core Execution Semantics: Guided Hands-On Workflow

1. Safe lab boundary and preflight

Create a temporary directory such as rf07-built-in-lab. This chapter requires only Robot Framework core/BuiltIn and synthetic strings/numbers. It does not touch a browser, API, database, SSH host, filesystem outside the lab directory, container runtime, CI account, or production service.

2. Create the project layout

rf07-built-in-lab/
├── suites/
│   ├── workflow.robot
│   └── failure.robot
└── evidence/
    ├── workflow/
    └── failure/

3. Build the passing workflow suite

*** Settings ***
Documentation    BuiltIn-only Chapter 07 workflow.
Test Teardown    Log To Console    TEARDOWN:${TEST NAME}:${TEST STATUS}

*** Test Cases ***
Logging Conversion And Introspection
    Log    Starting synthetic validation at INFO
    Log To Console    TEST=${TEST NAME}
    ${workers}=    Convert To Integer    3
    Should Be Equal    ${workers}    ${3}
    Should Be True    $workers >= 1
    Keyword Should Exist    Should Be Equal
    Variable Should Exist    ${TEST NAME}

Native Recovery For Expected Failure
    TRY
        Should Be Equal    actual    expected
    EXCEPT    actual != expected
        Log    Expected mismatch was handled intentionally.
    END
    Should Be Equal    recovered    recovered

Status Capture With Explicit Decision
    ${ok}=    Run Keyword And Return Status
    ...    Should Be Equal    alpha    beta
    Should Be Equal    ${ok}    ${False}
    IF    not $ok
        Log    Optional comparison failed as expected.
    END

4. Run the passing suite and inspect evidence

# Bash / Git Bash / macOS / Linux
python -m robot --outputdir evidence/workflow suites/workflow.robot

# PowerShell
python -m robot --outputdir evidence/workflow suites/workflow.robot

Expected result: three tests pass. The console shows each teardown after its test, proving teardown is part of lifecycle rather than a step that only runs on green paths. Open evidence/workflow/log.html and expand the TRY branch and the status-capture keyword. Their source intent is similar, but their result hierarchy is visibly different.

5. Compare native TRY with status-returning BuiltIn

6. Assertion messages should explain the contract

BuiltIn assertions allow custom messages and several comparison modes. A useful failure tells the operator what invariant was violated, not only that two values differ.

*** Test Cases ***
Contextual Assertion
    VAR    ${expected}    ready
    VAR    ${actual}      pending
    Run Keyword And Expect Error
    ...    *Deployment gate expected ready but saw pending*
    ...    Should Be Equal
    ...    ${actual}
    ...    ${expected}
    ...    Deployment gate expected ${expected} but saw ${actual}

Run Keyword And Expect Error is appropriate here because the test is specifically testing failure behavior. Do not wrap a real release assertion this way.

7. Create an intentionally failing suite to prove teardown semantics

*** Settings ***
Test Teardown    Log To Console    CLEANUP:${TEST NAME}:${TEST STATUS}

*** Test Cases ***
Required Gate Fails Transparently
    Log To Console    BEFORE ASSERTION
    Should Be Equal
    ...    pending
    ...    ready
    ...    Required gate is not ready
    Log To Console    THIS LINE SHOULD NOT RUN

8. Preserve the failing run

python -m robot --outputdir evidence/failure suites/failure.robot

Expected result: process/test failure. THIS LINE SHOULD NOT RUN is absent, but CLEANUP:Required Gate Fails Transparently:FAIL should appear because teardown executes after the main-body failure. Preserve evidence/failure/output.xml, log.html, and report.html; do not overwrite them with a fixed run.

9. Observe log levels without exposing secrets

Use only synthetic values. Run the passing suite once at DEBUG if you want richer diagnostics. Do not use a real credential at TRACE. TRACE can include keyword arguments and return values. If you want to demonstrate Secret masking, use a fake Secret value and keep it inside Secret-aware paths.

python -m robot --loglevel DEBUG --outputdir evidence/debug suites/workflow.robot

10. Small challenge: choose the correct control

A validation keyword may legitimately return “resource not present,” and the test should continue to an alternate local fixture. Do you use a direct assertion, native TRY/EXCEPT, Run Keyword And Continue On Failure, or Run Keyword And Return Status?

A strong answer chooses native TRY/EXCEPT when absence is expressed as an expected keyword failure and recovery is meaningful, or a Boolean-returning helper only when Boolean status is the explicit contract. Run Keyword And Continue On Failure is wrong if the final test should remain PASS, because it preserves failure status.

11. Verification checklist and cleanup

• Robot/Python versions were recorded.
• The passing workflow produced output.xml, log.html, and report.html.
• Native TRY recovered only the expected mismatch.
• The status-returning example explicitly asserted/handled False.
• The intentionally failing test stopped its main body but still ran teardown.
• No real secret, external endpoint, or destructive resource was used.

Cleanup is simply deleting the disposable rf07-built-in-lab directory after you no longer need the evidence.

12. Knowledge check

13. Summary and next step

You have now observed BuiltIn behavior instead of memorizing it: assertions changed status, native TRY handled an expected failure, status capture produced explicit data, and teardown ran after failure. Lesson 3 turns those mechanics into production design choices around control syntax, conversion, Evaluate, log verbosity, and retry strategy.

Further reading

• Robot Framework 7.4.2 BuiltIn library documentation — current keyword signatures, argument types, status/control helpers, logging, assertions, conversion, and retry semantics.
• Robot Framework 7.4.2 User Guide — Control structures — native IF/ELSE, TRY/EXCEPT, loops, BREAK/CONTINUE, and modern execution flow.
• Robot Framework 7.4.2 User Guide — TRY/EXCEPT — native failure handling and matching semantics.
• Robot Framework 7.4.2 User Guide — Log levels — INFO/DEBUG/TRACE behavior and execution evidence.
• Robot Framework 7.4.2 User Guide — Secret variables — masking boundaries for confidential values.
• Robot Framework 7.4.2 release and 7.5b1 pre-release — release status used by this chapter.