Checkpoint Lab — Robot Framework Foundations, ATDD, BDD, RPA, and Use Cases

1. Automation charter

Your demo domain is a fictional release-candidate handoff. The automation must do two different jobs without confusing them:

• Test: verify that the synthetic candidate has status ready.
• Task: produce a harmless console/log message stating that the synthetic candidate would be prepared for handoff.

The lab must also classify what belongs to Robot Framework core, what belongs to BuiltIn, and what would require an external library in a real system.

2. Preflight and exact assumptions

Compatibility baseline checked 2026-08-30:

• Robot Framework: 7.4.2 stable.
• Python: 3.8 or newer.
• Libraries: BuiltIn only; automatically available.
• Pabot/browser/CI/container tooling: not required.
• Target: local synthetic values only.

python --version
python -m robot --version
python -m pip show robotframework

If Robot Framework is not installed, Chapter 02 teaches environment setup in detail. For this checkpoint, use an isolated environment and pin robotframework==7.4.2 rather than installing into a system Python blindly.

3. Create the disposable layout

rf-ch01-checkpoint/
├── release_test.robot
├── release_task.robot
└── results/
    ├── test-pass/
    ├── test-fail/
    └── task/

Before running anything, make two predictions:

1. The synthetic values in the source files will not be modified by the runs.
2. Each run will create or update only its selected result directory and will not touch an external system.

Write those predictions down. A checkpoint lab should test your mental model, not only your typing.

4. Implement the tiny acceptance test

*** Settings ***
Documentation    Chapter 01 synthetic acceptance test.

*** Variables ***
${CANDIDATE}    build-142
${STATUS}       ready

*** Test Cases ***
Release Candidate Is Ready
    [Documentation]    Verify a harmless local readiness rule.
    Log    Candidate=${CANDIDATE}
    Should Be Equal    ${STATUS}    ready

Run it into a dedicated directory:

python -m robot --outputdir results/test-pass release_test.robot

Expected: one PASS test and three standard result files. Open the log and locate the nested Log and Should Be Equal calls.

5. Implement the tiny task

*** Settings ***
Documentation    Chapter 01 harmless synthetic RPA-style task.

*** Variables ***
${CANDIDATE}    build-142

*** Tasks ***
Prepare Synthetic Handoff
    [Documentation]    Demonstrate task terminology without changing a system.
    Log    Candidate ${CANDIDATE} would be prepared for handoff.    console=True

python -m robot --outputdir results/task release_task.robot

The task PASS means the defined task body completed. It does not prove that a real release was promoted, because no release system exists in this lab. That distinction is intentional.

6. Produce the architecture diagram

flowchart TD
A[release_test.robot] --> R[Robot core]
B[release_task.robot] --> R
R --> BI[BuiltIn]
BI --> V[Synthetic in-memory values]
R --> T1[Test PASS/FAIL]
R --> T2[Task PASS/FAIL]
T1 --> O1[results/test-*]
T2 --> O2[results/task]
O1 --> E[output.xml / log.html / report.html]
O2 --> E
X[Real API/browser/database] -. not used .-> BI

Explain every arrow in your own words. In particular, the dotted non-connection to real systems is part of the evidence: you designed the lab so external production state is out of scope.

7. Inject one reversible failure

Copy release_test.robot or edit the synthetic variable so that ${STATUS} is blocked. Do not change the expected value. Run the failing version into a different directory:

python -m robot --outputdir results/test-fail release_test.robot

Expected: the assertion fails. Preserve the failed log and XML. Then restore ${STATUS} to ready. Do not delete the failure artifacts; the point is to retain both sides of the diagnosis.

8. Build the evidence packet

Your checkpoint packet should contain:

• Python and Robot Framework version output.
• The two source files.
• The exact commands used for the pass, task, and controlled-failure runs.
• results/test-pass/output.xml, log.html, and report.html.
• results/task/output.xml, log.html, and report.html.
• results/test-fail/ artifacts preserving the first failure.
• The architecture diagram or a text equivalent.
• A one-paragraph explanation of what state changed and what state did not exist in this lab.

In a real CI system these artifacts would be retained according to policy even when a run fails. Later chapters cover CI and output governance.

9. Verification checklist

• The test PASSes when status is ready.
• The task PASSes and produces only a harmless message.
• The controlled failure remains preserved in a separate directory.
• No external domain library was installed or imported for the mandatory path.
• No real credential, production URL, personal path, or sensitive payload appears in source or results.
• You can identify Robot core, BuiltIn, source variables, test/task result state, and output artifacts as separate concerns.
• You can explain why a browser/API/database action would need another library.

10. Cleanup and rollback

There is no remote rollback because the lab changed no remote system. Cleanup consists only of removing the disposable rf-ch01-checkpoint directory after you have finished reviewing evidence. Verify your current directory and target path before recursive deletion. If you created a temporary virtual environment solely for the lab, remove it only with the rest of the disposable directory.

11. Knowledge check

12. What Chapter 01 adds to a production operating model

You can now describe Robot automation as a controlled chain: intent → suite/test/task → keyword resolution → library boundary → external or synthetic state → explicit status → retained result evidence. You can distinguish test verification from task execution, BDD wording from a separate engine, core behavior from domain libraries, and first-failure diagnosis from retry-based masking.

Further reading and current primary references

Version-sensitive statements in this lesson were checked on 2026-08-30. The mandatory path uses Robot Framework 7.4.2, the current stable release at the time of authoring. Robot Framework 7.5b1 is a pre-release and is not required here. Re-check these sources before pinning versions in a new environment.

• Robot Framework 7.4.2 User Guide
• BuiltIn library 7.4.2 documentation
• RFCP syllabus — purpose and use cases
• RFCP syllabus — architecture of Robot Framework
• RFCP syllabus — basic syntax and structure
• RFCP syllabus — keyword-driven, behavior-driven, and data-driven styles
• Robot Framework releases
• Robot Framework on PyPI