Welcome

• Wi-Fi, power, toilets
• Breaks every ~90 minutes
• Questions anytime — interrupt me
• First half: presentation + demos
• Second half: hands-on exercises

All material: hackxit.github.io/42vienna-robotframework-workshop

Today's Agenda

1. Welcome & environment setup
2. What is Robot Framework?
3. Architecture & ecosystem
4. Syntax walkthrough
5. Browser Library & Playwright
6. Hands-on exercises
7. AI-assisted testing demo
8. PR submission & CI results

Slides cover points 1–5, then we switch to live coding

Setup (Do This Now)

1. Go to github.com/HackXIt/42vienna-robotframework-workshop
2. Click "Fork" (top-right)
3. On your fork: Code → Codespaces → Create codespace on main
4. Wait ~3–5 minutes for the build

This installs Python, Node.js, Robot Framework, Browser Library, and Chromium — all automatic.

Verify Your Setup

When your Codespace terminal is ready, run:

uv run robot tests/00_setup_verification/

You should see:

1 test, 1 passed, 0 failed

Problems? Run python scripts/check_environment.py for diagnostics.

Robot Framework at a Glance

• Open-source automation framework (Apache 2.0)
• Built with Python, extensible via Python libraries
• Created 2005, maintained by the RF Foundation
• Keyword-driven — tests read like English
• One syntax, one reporting format, many domains

One Framework, Many Domains

Compare: Cypress = web only. Postman = API only. Appium = mobile only.
Robot Framework = one syntax across all of them.

Primary Use Cases

Not typically used for: unit testing, component testing (use pytest, JUnit instead)

Where RF Fits in Testing Levels

▲ Acceptance / E2E Testing   ← Robot Framework
▲ System Integration Testing  ← Robot Framework
▲ System Testing                ← Robot Framework
▲ Integration Testing           ← rarely RF
▲ Unit / Component Testing      ← pytest, JUnit
  

RF operates at higher test levels, automating real user workflows

Core Components

• Parser — reads .robot files, builds execution model
• Execution Engine — runs keywords, manages flow
• Result Generator — produces log.html, report.html, output.xml
• Standard Libraries — BuiltIn, Collections, String, OperatingSystem, ...
• Extension APIs — write your own libraries in Python

Three-Layer Architecture (gTAA)

Aligned with the ISTQB Generic Test Automation Architecture

What RF Does NOT Provide

• No built-in web, API, mobile, or database keywords
• No IDE or code editor
• No CI/CD integration

These come from the ecosystem:
Libraries, editors (RobotCode, RIDE), CI tools (GitHub Actions, Jenkins)

This is by design — RF is the framework, not the toolbox.

Today's Stack

Your Test Cases  ← you write these
       ↓
Robot Framework  ← parses & executes
       ↓
Browser Library  ← Playwright wrapper (adaptation layer)
       ↓
Playwright       ← browser automation engine
       ↓
Chromium         ← the actual browser
  

Design Principles

• Space-separated syntax — 2+ spaces = separator
• Indentation-based blocks (like Python)
• Minimal special characters
• String-first — everything is a string unless explicitly a variable
• Case-insensitive keywords and variables

Convention: use 4 spaces between keyword and arguments for clarity

File Types

A directory containing .robot files is also a suite — forming a hierarchy.

The Four Sections

*** Settings ***
Documentation     What this suite is about
Library           Browser
Resource          ../resources/common.resource

*** Variables ***
${URL}    https://www.saucedemo.com
${USER}   standard_user

*** Test Cases ***
My First Test
    [Documentation]    Verify login works
    Log    Hello World

*** Keywords ***
My Custom Keyword
    [Arguments]    ${arg1}
    Log    Got: ${arg1}

The Separator Rule

The most important syntax concept:

# This works (4 spaces between keyword and args):
Click    id=login-button

# This ALSO works (2 spaces):
Click  id=login-button

# This FAILS (only 1 space):
Click id=login-button
#     ^^^^^^^^^^^^^^^^
# RF thinks the keyword name is "Click id=login-button"

Rule: 2+ spaces (or tab) = argument separator
Convention: Use 4 spaces for readability

Variables

*** Variables ***
${SCALAR}     single value           # String
${NUMBER}     ${42}                  # Integer
${BOOL}       ${True}                # Boolean
@{LIST}       item1    item2         # List
&{DICT}       key1=val1  key2=val2   # Dictionary

*** Test Cases ***
Using Variables
    Log    ${SCALAR}         # single value
    Log    ${LIST}[0]        # item1
    Log    ${DICT}[key1]     # val1

${} = scalar    @{} = list    &{} = dictionary

Two Types of Keywords

Login As Standard User
    Fill Text    id=user-name
    ...          standard_user
    Fill Text    id=password
    ...          secret_sauce
    Click        id=login-button

# Python behind "Fill Text":
def fill_text(selector, text):
    page.locator(selector)
        .fill(text)

Keyword-Driven (Imperative)

"What actions to perform"

*** Test Cases ***
Purchase A Product
    Login With Credentials    standard_user    secret_sauce
    Add Product To Cart       Sauce Labs Backpack
    Open Cart
    Proceed To Checkout
    Fill Checkout Info        John    Doe    12345
    Complete Purchase
    Verify Order Confirmation

Procedural, step-by-step — great for technical audiences

Behavior-Driven (Declarative)

"How the system should behave"

*** Test Cases ***
User Can Purchase A Product
    Given the user is logged in as "standard_user"
    When the user adds "Sauce Labs Backpack" to the cart
    And the user completes checkout with name "John Doe"
    Then the order confirmation should be displayed

Given/When/Then/And/But prefixes are stripped by RF at runtime
Maps to user stories — great for stakeholder communication

Data-Driven (Template)

"Same flow, different data"

*** Test Cases ***          USERNAME            PASSWORD        EXPECTED
Valid Login                  standard_user       secret_sauce    Products
Locked User                  locked_out_user     secret_sauce    locked out
Wrong Password               standard_user       wrong_pass      do not match
Empty Username               ${EMPTY}            secret_sauce    Username is required

*** Keywords ***
Login And Verify
    [Arguments]    ${username}    ${password}    ${expected}
    Login With Credentials    ${username}    ${password}
    # ... verify expected outcome

Uses [Template] — each row is a test case with different data

Style Comparison

In practice: keyword-driven is the most common style. Today's workshop uses keyword-driven.

The Page Object Pattern

test_login.robot
     imports ↓
login_page.resource  ←  keywords: Login With Credentials, Login Should Fail, ...
     imports ↓
common.resource     ←  keywords: Open SauceDemo, Close SauceDemo
     imports ↓
Browser Library     ←  keywords: Click, Fill Text, Get Text, Get Url, ...
  

Each page of the application gets its own resource file.
Tests use descriptive keyword names, not raw CSS selectors.

Resource File Example

*** Settings ***
Documentation     Login page keywords for SauceDemo
Library           Browser

*** Variables ***
${LOGIN_USER_FIELD}     id=user-name
${LOGIN_PASS_FIELD}     id=password
${LOGIN_BUTTON}         id=login-button
${ERROR_CONTAINER}      css=.error-message-container

*** Keywords ***
Login With Credentials
    [Documentation]    Fill username/password and click login
    [Arguments]    ${username}    ${password}
    Fill Text    ${LOGIN_USER_FIELD}    ${username}
    Fill Text    ${LOGIN_PASS_FIELD}    ${password}
    Click        ${LOGIN_BUTTON}

Selector changes? Update one file, not every test.

Our Project Structure

tests/
  00_setup_verification/    # Smoke test
  01_first_test/            # Intro with comments
  02_login_tests/           # Login page tests
  03_product_tests/         # Product catalog
  04_cart_tests/             # Shopping cart
  05_checkout_tests/         # Checkout flow
  06_e2e_scenarios/          # Full purchase flow
  student_exercises/         # YOUR tests go here

resources/
  common.resource            # Setup/teardown, base URL
  login_page.resource        # Login keywords
  products_page.resource     # Products keywords
  cart_page.resource          # Cart keywords
  checkout_page.resource      # Checkout keywords

Setup & Teardown Levels

*** Settings ***
Suite Setup       Open SauceDemo
Suite Teardown    Close SauceDemo
Test Setup        Go To    ${BASE_URL}

Tags

*** Test Cases ***
Login With Valid Credentials
    [Tags]    smoke    login    positive
    Login With Credentials    standard_user    secret_sauce
    Login Should Succeed

Run subsets by tag:

# Only smoke tests
uv run robot --include smoke tests/

# Everything except slow tests
uv run robot --exclude slow tests/

# Combine: smoke AND login
uv run robot --include smokeANDlogin tests/

Why Browser Library?

Browser Lifecycle

*** Keywords ***
Open SauceDemo
    New Browser    chromium    headless=${HEADLESS}
    New Context
    New Page       ${BASE_URL}

Browser = Chromium/Firefox/WebKit process
Context = isolated session (cookies, storage)
Page = a tab

Selectors

# By ID (most reliable)
Click    id=login-button

# By CSS selector
Click    css=.inventory_item_name
Get Text    css=.shopping_cart_badge    ==    1

# By text content
Click    text=Sauce Labs Backpack

# Combined
Click    css=.btn_primary >> text=Add to cart

Browser Library uses Playwright selectors — powerful, auto-waiting.

Key Keywords

Built-in Assertions

# Exact match
Get Text    css=.title    ==    Products

# Contains
Get Text    css=.error    *=    locked out

# Starts with
Get Url    ^=    https://www.saucedemo.com

# Greater/less than (for counts, prices, etc.)
Get Element Count    css=.inventory_item    >=    1

No need for separate Should Be Equal — assertions are built into getter keywords.

SauceDemo — Test Users

Password for all users: secret_sauce

SauceDemo — User Flow

Login  →  Products  →  Cart  →  Checkout Info  →  Checkout Overview  →  Confirmation
  

This is the complete E2E flow you'll automate in the exercises.

What Happens When You Push

You push code
       ↓
GitHub Actions triggers
       ↓
  ├ Robocop lint → code quality check (SARIF → Code Scanning)
  └ Robot Framework → runs ALL tests in headless Chromium
       ↓
Results posted as PR comment
  

Example PR Comment

29 tests, 29 passed, 0 failed

Every PR gets automated feedback — no manual test running needed.

RFCP Certification

What we covered maps to the official RFCP syllabus:

Exercise Flow

1. Create your test file:
   cp tests/student_exercises/_template.robot tests/student_exercises/yourname_exercise_1.robot
2. Write tests (follow the exercises page)
3. Run: uv run robot tests/student_exercises/yourname_*.robot
4. Check results/log.html
5. Commit, push, create PR

I'll walk around and help. Ask questions!

The Idea

1. Describe a test scenario in natural language
2. AI generates a .robot file
3. Review — does it make sense?
4. Run it
5. Refine

AI doesn't replace testers — it accelerates test creation.
You design the strategy. AI generates the boilerplate.

Submitting Your Work

# Stage your files
git add tests/student_exercises/yourname_*.robot

# Commit
git commit -m "Add exercises by yourname"

# Push to your fork
git push origin main

Then on GitHub: Contribute → Open pull request

CI will run automatically and post results on your PR!

What You Learned Today

• Robot Framework — generic automation framework
• Three-layer architecture (Definition, Execution, Adaptation)
• Keyword-driven, BDD, and data-driven styles
• Browser Library + Playwright for web testing
• Page object pattern with resource files
• CI/CD — tests run automatically on every PR
• AI can help generate tests, but you validate them

Want More?

• robotframework.org — official docs
• RFCP Syllabus — certification pathway
• Browser Library Docs — all keywords
• Optional Practice Sites — more targets
• This Repository — keep using it!