Robot Framework Foundations, ATDD, BDD, RPA, and Use Cases: Configuration, Design Patterns, and Trade-Offs

1. Start with the problem, not the framework

A good automation architecture asks which layer can prove the requirement with the least cost and ambiguity. A pure function is usually best covered by a unit test. A service contract can often be covered at an API/component layer. A user journey may need a browser. An acceptance criterion may benefit from readable high-level Robot keywords that orchestrate one or more technical layers. An RPA job may need task semantics and operational safeguards.

Robot Framework can technically call almost anything through libraries, but technical possibility is not the same as architectural fit. Overusing end-to-end automation makes failures slower and harder to localize; overusing low-level tests can miss system integration and business intent.

2. Decision table — what are you trying to prove or perform?

3. Tests versus tasks: failure means different things operationally

Both tests and tasks can execute keywords and can PASS or FAIL, but you should interpret the status in context. In a test, a failed assertion normally means the observed system behavior did not satisfy the expected condition. In a task, a failure may mean an operation could not complete, a precondition was not met, or an external system returned an error.

For RPA, a single PASS is not durable workflow state. If a process spans hours, human approval, external queues, retries, or resumable checkpoints, durable state often belongs in a workflow system, database, or application—not only inside a Robot process or suite variable.

4. Imperative keyword-driven versus declarative BDD-style wording

BDD prefixes do not create a separate runtime. The design value comes from the language level: a high-level step should describe behavior, while lower-level keywords implement details. A page-long Given/When/Then scenario with every click and selector spelled out is still procedural automation wearing BDD vocabulary.

5. Business keywords versus implementation keywords

*** Test Cases ***
Candidate Is Ready For Promotion
    Verify Candidate Is Ready For Promotion    build-142

*** Keywords ***
Verify Candidate Is Ready For Promotion
    [Arguments]    ${candidate}
    ${status}=    Get Synthetic Candidate Status    ${candidate}
    Should Be Equal    ${status}    ready

Get Synthetic Candidate Status
    [Arguments]    ${candidate}
    Log    Reading synthetic status for ${candidate}
    RETURN    ready

The test now expresses intent in one call. The user keyword owns acceptance-level meaning; a lower keyword produces technical data; BuiltIn performs the assertion. In a later API or database chapter, Get Synthetic Candidate Status could delegate to an external library. The test should not need to know whether the status came from HTTP, SQL, or a stub unless that transport is part of the requirement.

Do not hide every failure behind a giant keyword, though. A high-level keyword should remain diagnosable: meaningful nested calls, precise assertions, and preserved external evidence matter more than an artificially short test body.

6. Generic core versus domain-specific libraries

The core provides parsing, execution, variable and keyword semantics, built-in generic facilities, APIs, and result generation. Domain libraries add adaptation. That separation has consequences:

• A browser-library upgrade can change browser behavior without changing Robot core.
• An HTTP library can own connection/session behavior that a Robot suite does not automatically reset.
• A Python library's instance scope can outlive a single keyword call and therefore hold mutable state.
• CI can rerun Robot in a new process even though the application under test still contains durable data from a previous run.

Production troubleshooting must record versions and state for each layer separately.

7. Trade-offs that affect maintainability and CI reliability

8. Current ecosystem boundaries

As of 2026-08-30, Robot Framework 7.4.2 is stable and 7.5b1 is a pre-release. The RFCP syllabus version 1.1.0 uses a useful three-layer framing: definition layer (tests/tasks/resources), execution layer (Robot core), and adaptation layer (keyword libraries). RobotCode, Pabot, Robocop, Browser, SeleniumLibrary, and CI systems remain separate projects/tools with their own release cycles.

9. Worked scenario — release-readiness requirement

Requirement: "A candidate may be promoted only when status is ready and the automated evidence packet is retained." Three designs are possible:

1. Unit-only: test a readiness function. Fast, but does not prove the system exposes the right status or that pipeline evidence is retained.
2. Robot acceptance test: high-level keyword reads status through a domain library, asserts the business outcome, and preserves result artifacts. Good when the requirement is cross-system and stakeholder-readable.
3. Robot task: perform promotion. That is a different concern and carries destructive/authorization risk. It should not be smuggled into the acceptance test merely because the same framework can call the required API.

The recommended split is to test readiness independently from the promotion task. This reduces blast radius and makes failure semantics explicit.

10. Hands-on design lab

Choose three automation requests from the following list and classify each: unit/component/API/system/acceptance test or RPA task. Then identify whether Robot core alone is sufficient or whether a library would be needed.

• Compare two synthetic strings.
• Verify a real browser login journey in an authorized test environment.
• Read an application health endpoint.
• Rotate a production database password.
• Generate a local synthetic handoff message.
• Verify a pure Python parser function.

The production-password rotation item is intentionally unsafe for this course lab. The correct design response is not "use SSHLibrary" or "use DatabaseLibrary"; it is to reject the uncontrolled production target and redesign with an authorized disposable environment plus explicit change-management controls.

11. Knowledge check

12. Summary and next step

Good Robot Framework design starts by choosing the right automation layer, then choosing a specification style and keyword abstraction level that preserve intent without hiding diagnosis. Tests, tasks, user keywords, libraries, CI, and external systems have different ownership and state. Lesson 4 applies that architecture to realistic failure modes and a disciplined diagnostic sequence.

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