Robot Framework: plain text acceptance testing and RPA, reviewed

What Robot Framework actually solves, and for whom

Acceptance tests tend to rot because the people who know the business rules cannot read the code that verifies them. Robot Framework attacks that gap with a syntax that is deliberately not a programming language. A test suite is a text file with Settings, Test Cases and keyword lines, and the README's own example reads as a short recipe: open a browser to the login page, input a username, input a password, submit, then assert the welcome page is open. A product owner can review that file without opening an IDE.

The audience is therefore three overlapping groups. QA engineers writing acceptance tests, teams practising acceptance test driven development, and RPA developers automating back-office work. The README lists all three explicitly. The project is operating system and application independent, implemented in Python, and the primary extension language is also Python. Version 7.5 was released on 2026-09-14, and the last push to master was on 2026-09-21, so this is not a dormant repository.

One thing the README is honest about: the framework itself is a runner and a syntax. The rich ecosystem of libraries and tools around it is developed as separate projects. That single sentence explains most of the friction new users hit, and most of the confusion in the questions people ask about it.

The execution model: robot, rebot and keyword libraries

Tests are executed from the command line with the robot command, or by invoking the module as python -m robot. The command takes a path to a file or directory plus options placed before that path. The README shows the shape: robot tests.robot for the simplest case, and robot --variable BROWSER:Firefox --outputdir results path/to/tests/ when you need to override a variable and redirect output. Options come before the path, which is a common first mistake.

A second binary, rebot, post-processes results rather than running tests. It combines and otherwise post-processes outputs, and the README's example is rebot --name Example output1.xml output2.xml. That matters in CI: you can split a suite across parallel jobs, then merge the XML into one report with a single name. Neither robot nor rebot is a test library. They parse the suite, resolve keywords, execute steps, and write logs and reports.

Keywords are the unit of composition. Some are built into the framework's standard libraries, listed in the documentation index. Others come from imported resource files, as in the README example where Resource login.resource supplies Open Browser To Login Page, Input Username and the rest. The framework resolves those names at runtime. This indirection is the design's strength (readable tests) and its main debugging cost: a typo in a keyword name fails at execution, not at parse time in your editor.

Installing Robot Framework and running a first suite

The README gives one install command for anyone who already has Python and pip. It requires Python 3.8 or newer and also runs on PyPy. If you are pinned to Python 3.6 or 3.7, the README points to Robot Framework 6.1.1 as the last version supporting those interpreters; Python 2, Jython and IronPython users are pointed at 4.1.3. Downloads are hosted on PyPI.

pip install robotframework

After that, confirm the entry point exists before writing anything. The README says to run robot --help and rebot --help for command line usage. If robot is not found, the module form python -m robot is the documented fallback, which usually means the scripts directory is not on your PATH.

robot --help
rebot --help

Now a minimal suite. Save this as login.robot. It follows the structure of the README example, keeping the documentation and teardown settings the README shows. The [Teardown] line runs even when the test body fails, which is how you avoid leaving a browser process behind.

*** Settings ***
Documentation     A test suite with a single test for valid login.
...
...               This test has a workflow that is created using keywords in
...               the imported resource file.
Resource          login.resource

*** Test Cases ***
Valid Login
    Open Browser To Login Page
    Input Username    demo
    Input Password    mode
    Submit Credentials
    Welcome Page Should Be Open
    [Teardown]    Close Browser

Run it with a variable override and a separate output directory, matching the option pattern from the README. You should see a pass line for Valid Login, and the results directory should contain the log and report files that rebot can later combine.

robot --variable BROWSER:Firefox --outputdir results path/to/tests/

To see the post-processing path, run rebot against the generated XML, or against two files if you split the run. The --name flag sets the title shown in the merged report.

rebot --name Example output1.xml output2.xml

Where the core stops: no browser, no desktop, no assertions about your app

The most common wrong expectation is that pip install robotframework gives you a browser automation tool. It does not. The README's example test calls Open Browser To Login Page, but that keyword is not defined in the framework; it comes from login.resource, which in turn would import a library such as SeleniumLibrary or Browser. Those are separate projects with their own release cycles, their own Python version support and, as the README notes, possibly different licences from Apache-2.0.

That has a concrete consequence for upgrades. Bumping Robot Framework to 7.5 does not bump your browser driver, your Playwright or Selenium version, or your desktop automation library. A framework upgrade that changes keyword resolution can surface as failures in a library you did not touch. The README does not document a rollback procedure for library or framework upgrades, so plan to pin versions in your own requirements file and test the combination before rolling it out.

There is a second boundary. Robot Framework is a test and task runner, not a test generator. It will not infer assertions from your application, and the plain text syntax will not catch a keyword name that no imported library defines until the suite runs. Teams that want static checking of keyword names need editor tooling from the ecosystem, which the README points to only through the general documentation site. If your team is unwilling to maintain that tooling, the readability gain is partly paid back in slower feedback.

Robot Framework compared with writing pytest tests directly

The natural alternative for a Python team is pytest, and the difference is not cosmetic. In pytest, a test is a Python function. Fixtures, parametrisation, assertions and mocking are Python constructs, and your editor, type checker and debugger understand all of it. In Robot Framework, a test is a table of keyword calls parsed by the framework, and the extension point is writing keyword libraries in Python.

That means the two tools optimise for different readers. pytest optimises for the developer who already writes Python and wants no new syntax. Robot Framework optimises for the reviewer who does not, and for suites where the same keyword vocabulary is reused across many test cases and RPA tasks. The README's plain text syntax and simple keyword structure are the whole point; if nobody outside the engineering team will read the tests, you are paying the parsing and indirection cost for a benefit you are not collecting.

A second alternative is a record-and-replay commercial tool, which inverts the trade-off again: you get a generated script quickly and lose the reviewable plain text file. Robot Framework sits between the two. It is code-adjacent enough to live in Git and be reviewed, and abstract enough that a non-programmer can read a suite, provided the keyword names were chosen well by whoever wrote the libraries.

Licence, versioning and the real cost of staying current

The framework is provided under the Apache License 2.0, and the documentation and similar content use Creative Commons Attribution 3.0 Unported. The README is explicit that most libraries and tools in the ecosystem are also open source but may use different licences. If you ship a product that bundles Robot Framework and a browser library, you are checking two licence sets, not one. That is a factual constraint, not legal advice; get your own review if the distinction matters to your distribution model.

The version in the repository's setup.py is 7.5.1.dev1, which is the development line after the 7.5 release on 2026-09-14. The release history shows a beta on 2026-07-17 and a release candidate on 2026-09-04 before the final. That cadence tells you what an upgrade costs: a beta and an RC exist to be tested against your libraries before the final lands, and skipping them means discovering incompatibilities in production CI. The classifiers in setup.py list Python 3.8 through 3.15 plus PyPy, so interpreter support is broad but not unlimited, and the 6.1.1 and 4.1.3 pointers in the README are the escape hatches for older runtimes.

Development is sponsored by the non-profit Robot Framework Foundation, and the README invites users who benefit from it to join. That is a funding model, not a support contract. If you need a guaranteed response time, the README offers Slack, a forum and a users mailing list, all community channels.

Editorial conclusion

Adopt Robot Framework if you want test cases and RPA tasks expressed in plain text that non-programmers can read, and you accept that browser, API and desktop drivers come from separate ecosystem projects. Do not adopt it if you need a single bundled tool that drives a browser out of the box, because the core package contains no SeleniumLibrary or Browser library. Verify first that your Python is 3.8 or newer and that you are installing from PyPI, then run robot --help to confirm the entry point is on your PATH.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. robotframework/robotframework on GitHub