Checkpoint Lab — BuiltIn Library and Core Execution Semantics

1. Scenario and safety boundary

You are validating a synthetic release manifest represented only by local strings and numbers. A missing optional annotation should be recoverable; a readiness state of pending instead of ready is a mandatory failure. The lab compares two ways to handle the optional check, then deliberately hides the mandatory failure so you can prove why the green result is wrong.

2. Create the lab layout and preflight

rf07-checkpoint/
├── suites/
│   ├── compare.robot
│   ├── swallowed.robot
│   └── repaired.robot
├── evidence/
│   ├── compare/
│   ├── swallowed/
│   └── repaired/
└── notes/
    └── predictions.md

Record:

python --version
python -m robot --version

Expected framework baseline: Robot Framework 7.4.2 stable. Record the actual values on your machine rather than copying the example blindly.

3. Write predictions before execution

4. Compare two recovery styles for an optional condition

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

*** Keywords ***
Optional Annotation Should Exist
    [Arguments]    ${manifest}
    Should Contain    ${manifest}    annotation=approved

*** Test Cases ***
A - Native TRY Recovery
    VAR    ${manifest}    state=ready
    TRY
        Optional Annotation Should Exist    ${manifest}
    EXCEPT    *does not contain*    type=GLOB
        Log    Optional annotation absent; using documented fallback.
    END
    Should Contain    ${manifest}    state=ready

B - Status Return Recovery
    VAR    ${manifest}    state=ready
    ${present}=    Run Keyword And Return Status
    ...    Optional Annotation Should Exist    ${manifest}
    IF    not $present
        Log    Optional annotation absent; using documented fallback.
    END
    Should Contain    ${manifest}    state=ready

5. Execute and compare result hierarchy

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

Expected overall status: PASS. In log.html, compare the native structural TRY branch with the nested Run Keyword And Return Status call. Both can be valid here because the annotation is explicitly optional, but the native structure exposes the recovery path more directly. Record the difference in notes/predictions.md.

6. Create the deliberately swallowed mandatory failure

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

*** Test Cases ***
Required Gate Is Accidentally Swallowed
    VAR    ${state}    pending
    ${ready}=    Run Keyword And Return Status
    ...    Should Be Equal
    ...    ${state}
    ...    ready
    ...    Required readiness gate failed
    Log To Console    READY=${ready}
    Log    The test reaches the end without consuming the false status.

7. Run and preserve the misleading green evidence

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

Expected Robot status: PASS even though the console shows READY=False. This is the key checkpoint finding. Copy the command, console observation, and result artifact paths into your notes. Do not delete or overwrite this run; it is evidence of a status-propagation defect, not a flaky test.

8. Repair the gate at the point of truth

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

*** Test Cases ***
Required Gate Propagates Transparently
    VAR    ${state}    pending
    Should Be Equal
    ...    ${state}
    ...    ready
    ...    Required readiness gate failed
    Log    This line must not run while state is pending.

9. Execute the repaired run separately

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

Expected Robot/process status: FAIL. That is the correct result because the synthetic release is not ready. The teardown should still execute and report FAIL. A “repair” that merely changes pending to ready would avoid testing the failure semantics; keep the input unchanged so the status difference is caused only by control design.

10. Required evidence packet

11. Verification checklist

• All mandatory examples use only Robot Framework core/BuiltIn and synthetic data.
• The comparison suite passes and records both native and status-return recovery.
• The swallowed suite passes while recording READY=False.
• The repaired suite fails with the same pending input.
• The repaired test does not execute the line after the direct failed assertion.
• Teardown executes after the repaired failure and sees ${TEST STATUS}=FAIL.
• First-failure/misleading-green artifacts remain preserved in separate directories.
• No real secret or external system was introduced.

12. Cleanup / rollback

After review, delete only the disposable rf07-checkpoint directory. There are no environment, account, service, or infrastructure changes to roll back. If you copied evidence into a CI artifact store, apply the project’s normal retention policy and verify it contains no sensitive values before upload.

13. Production BuiltIn governance checklist

• Required assertions are direct and have contextual messages.
• Every status-returning helper has an explicit consumer.
• Expected failures are narrowly matched; broad catches are reviewed.
• Continue-on-failure is used only to collect independent evidence and never described as recovery.
• Retries have an observable changing condition, bounded budget, and idempotent action.
• TRACE is disabled by default around plaintext credentials; Secret support is verified end-to-end.
• Evaluate is small and never built from untrusted text.
• Teardowns own cleanup, not “happy path” steps.
• CI retains the first meaningful failure rather than overwriting it with retries.

14. Knowledge check

15. Chapter checkpoint and bridge

You can now treat BuiltIn as a controlled execution interface rather than a shortcut catalog. You compared native and keyword-driven recovery, proved how a required failure can disappear into Boolean data, restored transparent failure propagation, and preserved artifacts that explain both behaviors. Chapter 08 expands outward from BuiltIn to the other standard libraries—Collections, String, DateTime, OperatingSystem, Process, and XML—while keeping the same ownership, safety, and evidence discipline.

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.