Robot Framework Notes for API Testing

Robot Framework gets dismissed as “old”, but for API regression suites that a mixed QA team needs to read and maintain, its keyword-driven style is hard to beat. These are the notes I hand to anyone starting an API suite with it.

Keep tests readable, keep logic in keywords

The rule I enforce: a test case should read like a sentence, and all the mechanics live in custom keywords. Compare a raw test to a keyword-driven one.

*** Settings ***
Library    RequestsLibrary
Library    Collections

*** Test Cases ***
Get User Returns Expected Profile
    Create Session    api    https://api.example.com
    ${resp}=    GET On Session    api    /users/42
    Status Should Be    200    ${resp}
    Should Be Equal    ${resp.json()}[name]    Ada Lovelace

That works, but the assertions leak HTTP details into the test. Wrapping them in keywords keeps intent front and center.

*** Keywords ***
Get User
    [Arguments]    ${user_id}
    ${resp}=    GET On Session    api    /users/${user_id}
    RETURN    ${resp}

Response Should Have Field
    [Arguments]    ${resp}    ${field}    ${value}
    Should Be Equal    ${resp.json()}[${field}]    ${value}

Structure that survives growth

A layout that has held up for me across several suites:

• resources/ — reusable keyword files, one per domain area
• variables/ — environment files (staging, prod) kept out of tests
• tests/ — the readable test cases, grouped by feature
• results/ — generated reports, git-ignored

Data-driven tests without duplication

For validation matrices, the Templates feature runs one keyword across many rows — ideal for boundary and negative cases.

*** Test Cases ***
Reject Invalid Emails
    [Template]    Create User Should Fail
    not-an-email
    missing@tld
    @no-local.com

What to assert, and what to skip

Assert the things a contract guarantees, and resist the urge to over-assert:

• Do assert: status code, required fields, types, and error messages
• Do skip: server-generated timestamps and IDs (match a pattern, not a value)

Where it fits

Robot Framework earns its place when the suite needs to be legible to manual testers and analysts, not just developers. If your team is fully engineering-led, a code-first framework may fit better — but for shared ownership, readability is a feature, not a compromise.