Robot Framework

Robot Framework is a keyword-driven automation framework. Tests are written as readable tables, keywords hide implementation details, and libraries provide the actual automation for browsers, mobile apps, APIs, files, databases, and custom systems.

This tutorial explains the Robot Framework structure and shows how to map common libraries to webmate-supported workflows. SeleniumLibrary can use remote Selenium endpoints, AppiumLibrary follows the Appium capability model, and API-focused libraries can exercise documented REST APIs.

Goal

By the end of this tutorial you will understand how to write a Robot suite, organize variables and resources, create reusable keywords, run reports, execute in CI, and choose the right webmate integration path for browser, mobile, or API tests.

Before You Start

You need Python, Robot Framework, and the libraries that match your test target. Typical projects install robotframework plus robotframework-seleniumlibrary for web tests, robotframework-appiumlibrary for mobile tests, or an HTTP library for API checks. Do this in the application test repository, not in this documentation repository.

Robot is most useful when the team values readable test intent. Keywords should be business-level enough to explain the workflow, but not so broad that they hide every meaningful failure.

Project Setup

A small Robot project can look like this:

1
2
3
4
5
6

tests/
  login.robot
resources/
  browser.resource
variables/
  staging.py

A minimal suite has settings, variables, and test cases:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

*** Settings ***
Library    SeleniumLibrary
Resource   ../resources/browser.resource

*** Variables ***
${BASE_URL}    https://docs.webmate.io/

*** Test Cases ***
Open Documentation Home Page
    Open Browser To Documentation
    Title Should Contain    webmate
    [Teardown]    Close Browser

The suite reads like a scenario, while the resource file owns setup details.

Step 1: Create Reusable Keywords

Resource files keep repeated steps in one place.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

*** Settings ***
Library    SeleniumLibrary

*** Keywords ***
Open Browser To Documentation
    Open Browser    ${BASE_URL}    chrome
    Maximize Browser Window

Search Documentation
    [Arguments]    ${term}
    Input Text    css:input[type="search"]    ${term}

Name keywords after user intent. Search Documentation is clearer than Input Search Field And Press Keys unless the low-level behavior is the point of the test.

Step 2: Use Variables for Environments

Robot supports scalar, list, and dictionary variables. Keep environment-specific values outside the suite where possible.

1
2
3
4

*** Variables ***
${BASE_URL}        %{BASE_URL=https://docs.webmate.io/}
${REMOTE_URL}      %{SELENIUM_REMOTE_URL=}
${BROWSER}         chrome

Environment variable syntax lets CI inject values without editing test files.

Step 3: Browser Tests With SeleniumLibrary

SeleniumLibrary wraps Selenium WebDriver in Robot keywords. For local execution, open a normal browser:

1
2
3
4
5

*** Test Cases ***
Search Page Loads
    Open Browser    ${BASE_URL}    ${BROWSER}
    Page Should Contain    webmate
    Close Browser

For remote execution, SeleniumLibrary can be configured with a remote URL and desired capabilities. Use this pattern when connecting to a Selenium Hub, including the documented webmate Selenium endpoint.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

*** Keywords ***
Open Remote Chrome
    ${caps}=    Create Dictionary
    ...    browserName=chrome
    ...    platformName=WINDOWS_11_64
    ...    browserVersion=latest
    ...    wm:apikey=%{WEBMATE_APIKEY}
    ...    wm:project=%{WEBMATE_PROJECTID}
    Open Browser
    ...    ${BASE_URL}
    ...    chrome
    ...    remote_url=%{SELENIUM_REMOTE_URL}
    ...    desired_capabilities=${caps}

Keep credentials in environment variables and keep capabilities close to browser setup.

Step 4: Mobile Tests With AppiumLibrary

AppiumLibrary uses Appium concepts in Robot syntax. The same cautions from Appium apply: use W3C capabilities, prefer accessibility identifiers, and quit sessions cleanly.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

*** Settings ***
Library    AppiumLibrary

*** Keywords ***
Open Android App
    Open Application    %{APPIUM_REMOTE_URL}
    ...    platformName=Android
    ...    appium:automationName=UiAutomator2
    ...    appium:appPackage=com.example.app
    ...    appium:appActivity=.MainActivity

Use this path when your team wants Robot’s keyword syntax on top of Appium. For webmate, validate capabilities against the App Testing documentation before assuming a device or Appium version is available.

Step 5: API Tests

Robot can also organize API checks. The exact library depends on your project, but the pattern is the same: create a session or request, assert status, and validate response fields.

1
2
3
4
5

*** Test Cases ***
API Health Check
    ${response}=    GET    ${BASE_API_URL}/health
    Should Be Equal As Integers    ${response.status_code}    200
    Should Contain    ${response.text}    ok

For webmate APIs, only test documented endpoints and keep API keys in secret storage. Use the docs under API and SDKs as the contract.

Step 6: Reports and CI

Robot produces output.xml, log.html, and report.html by default.

1

robot --outputdir results tests/

Filter tests with tags:

1

robot --include smoke --outputdir results tests/

CI should preserve the HTML log and report as artifacts. The log is often the fastest way to understand which keyword failed and what arguments it received.

How This Maps to webmate

Robot Framework itself is an orchestration layer. The webmate integration depends on the library underneath. SeleniumLibrary can map to webmate’s documented Selenium Hub path. AppiumLibrary can map to webmate’s documented Appium path when the capabilities match available devices and app setup. API libraries can call documented webmate REST endpoints.

Do not treat Robot as a separate webmate execution backend unless your project has verified infrastructure for it. Treat it as a readable suite format that can drive supported protocols and APIs.

Debugging

When a Robot test fails, start with log.html. Check the failing keyword, arguments, screenshots, and library message. If a browser or mobile session fails before the first app action, inspect remote URL, capabilities, credentials, and environment variables. If a high-level keyword fails often, split it into smaller keywords so the failure point is visible.

Verify the Result

A good Robot setup has clear suite files, reusable resource keywords, externalized secrets, useful tags, and preserved reports. The suite should make intent readable without hiding the technical detail needed to debug failures.

Next Steps

Use Selenium for the underlying browser automation model, Appium for mobile capability details, and REST API for documented webmate API workflows.