Articles
Robot Framework Interview Questions: Keywords, Fixtures, and Test Isolation
Prepare Robot Framework interview questions with reusable keywords, setup and teardown, a reproduced state leak, and practical test-isolation checks.
A Robot Framework test passes when selected alone but fails after another test. Adding a sleep makes the suite slower, not more reliable. The first question is not “Which wait keyword should I use?” It is “What state did the earlier test leave behind?”
Strong Robot Framework interview answers connect readable keywords to explicit ownership. Define what each keyword accepts, changes and verifies; choose fixture lifetimes deliberately; and distinguish a variable's scope from the lifetime of the object, library or external record it references. Isolation is a design property, not a consequence of putting tests in separate files.
Here, we examine a small, locally reproduced Robot Framework 7.5 failure and a repair. The example tests list state only; it does not validate a real browser, backend or parallel deployment.
What makes a useful Robot Framework keyword?
A keyword is a named operation that a test can call with arguments. It may be implemented in a test resource or provided by a library. Its name should express a meaningful operation, while its contract explains inputs, outputs, side effects and failure behavior.
Compare Click Button And Sleep And Get Text with Submit Valid Order. The second can describe business intent, but only if it does not hide the important assertion. If submitting and verifying are separate decisions, return the order identifier and let a clearly named assertion check the expected state. Readability should expose the oracle, not conceal it.
The Robot Framework style guide provides conventions for organizing tests, resources and keywords. Treat style as a way to make dependencies visible. A keyword that relies on a mysterious ${CURRENT_USER} set by another test is still coupled, however natural its sentence sounds.
In an interview, explain one boundary you would not abstract. Wrapping every standard keyword with an identical custom name creates another interface to maintain without adding domain meaning. Extract repeated policy or a coherent operation, not repetition measured solely by line count.
Choose fixtures by ownership, not by speed alone
A fixture establishes or releases the conditions under which a test runs. In Robot Framework, setup and teardown are keywords. A suite-level fixture surrounds a suite, while a test-level fixture surrounds each test. The official user guide describes their execution and override rules.
Sharing an expensive service process can be reasonable while giving each test independent records and sessions. Sharing a mutable shopping basket because creating it is inconvenient is different: one test can change another test's starting condition. The ownership question is more useful than a blanket “always use test setup” rule.
Write down the lifetime of each resource separately. A browser executable, browser context, logged-in account, tenant namespace, database transaction and created order do not necessarily share an owner. A cheap per-test context can sit inside expensive suite-level infrastructure.
Selenium's avoid-sharing-state guidance supports independent test data and cleanup. That principle transfers to Robot suites, but a particular library's reset or close keyword must still be checked against its actual behavior.
Reproduce a suite that leaks list state
Save this original example as leaky.robot. It uses only the standard Collections and BuiltIn libraries. The first test modifies a list defined at suite level; the second assumes that list is empty.
*** Settings ***
Library Collections
*** Variables ***
@{ITEMS}
*** Test Cases ***
Add One Item
Append To List ${ITEMS} apple
Length Should Be ${ITEMS} 1
Starts Empty
Length Should Be ${ITEMS} 0
On the local Robot Framework 7.5 run, Add One Item passed and Starts Empty failed: the list still contained apple. Running only Starts Empty in a new execution passed. These are observed outcomes from the saved fixture, not hypothetical timings or an interpretation of a production incident.
The Collections documentation identifies operations that mutate lists. Passing ${ITEMS} passes the list object as one argument; writing @{ITEMS} at an argument position expands its items. Confusing these forms can change the keyword call as well as obscure the mutation.
Notice what the failure does not prove. Robot Framework has not randomly reordered the data, and a longer wait cannot restore the intended initial condition. The defect is deterministic for this order: the second test inherits a modified object. That is a much smaller, more useful explanation than “the framework is flaky.”
Repair the starting condition with a fresh object
Save the repaired suite as isolated.robot. Each test receives a new list from its own setup, instead of depending on a previous test to undo a mutation.
*** Settings ***
Library Collections
Test Setup Create Empty Basket
*** Test Cases ***
Add One Item
Append To List ${ITEMS} apple
Length Should Be ${ITEMS} 1
Starts Empty
Length Should Be ${ITEMS} 0
*** Keywords ***
Create Empty Basket
${fresh}= Create List
Set Test Variable ${ITEMS} ${fresh}
Create List, Set Test Variable and the length assertion are documented in BuiltIn. The repair matters because it creates a different object, not because the variable name changed. Copying a reference into a test-scoped variable would still allow two references to mutate the same list.
The local repaired runs passed both tests in the original order and with --randomize tests:42; that seed put Starts Empty first. Checking both matters because passing only the convenient order would be weak evidence. Selecting each test alone and running multiple recorded orders extends coverage; no finite set of orders proves that all external state is isolated.
For nested data, a shallow copy is another trap. The outer dictionary can be new while a nested list remains shared. Prefer constructing the small fixture you need, or choose copying semantics deliberately and test object behavior. Do not announce “we copy the data” without naming which level becomes independent.
Separate variable, library and external-system state
Scope has several meanings. A test variable can disappear while its associated database record remains. A new Python library instance can coexist with a module-level cache. A fresh worker process can still use the same remote account as every other worker.
| State layer | Typical hidden coupling | Discriminating check |
|---|---|---|
| Robot variable or collection | Two names reference one mutable list | Create fresh objects and repeat the failing order |
| Library instance or module | Cache, connection or counter survives a test | Inspect library lifetime and reset behavior |
| External service or filesystem | Shared account, filename or database key | Use per-test ownership identifiers and inspect persisted records |
The user guide's library scope section distinguishes class-based TEST, SUITE and GLOBAL lifetimes. Library scope does not automatically reset the system under test. Ask what the imported library actually owns, and whether cleanup covers its internal state and external effects.
This distinction is especially useful in a review. “Move the variable to test scope” may fix the list example but do nothing for two tests that both write /tmp/result.json or update customer 123. The correct fix follows the shared resource, not the most visible variable declaration.
What happens when setup or teardown fails?
Robot executes a test teardown even when test setup fails; the normal test body does not run after a failed setup. Individual test fixture settings can override file-level defaults. These documented rules mean a test-specific override can accidentally remove essential cleanup.
Design cleanup for partial initialization. Suppose setup creates an account, then fails before assigning a browser handle. Teardown must not assume both resources exist. Register ownership as each acquisition succeeds, release only resources actually acquired, and preserve the original failure alongside cleanup errors.
Idempotent cleanup means a second attempt is safe, not that every failure is ignored. “Already absent” may be an acceptable delete result; “permission denied” or “wrong tenant” is not. A generic ignore-error wrapper can turn leaked data into an invisible long-term problem.
A useful interview exercise is to fail setup at three points: before allocation, after the first resource, and after full initialization. For each point, predict which cleanup operations are valid. This proposed fault-injection exercise is separate from the collection test we actually executed.
How should waits and retries fit the design?
Wait for an observable condition with a deadline, not an arbitrary pause chosen from the slowest recent run. For eventual consistency, specify which state transition is expected, how it is observed, how frequently it is checked, and what diagnostic evidence is kept on timeout.
BuiltIn's Wait Until Keyword Succeeds can repeat a keyword, but repetition is safe only when the operation tolerates it. Polling an order status is different from repeatedly creating the order. If a call may have succeeded before its response was lost, retrying the whole workflow can duplicate work and contaminate later tests.
Keep the assertion meaningful. A keyword that catches an error and returns a false value does not necessarily fail the Robot test unless the caller asserts on that value. Conversely, a broadly retried assertion may hide a product race. Explain whether the retry models an allowed business delay or merely suppresses evidence.
When a rerun passes, retain both observations. Record the original order, seed, environment and owned identifiers so the first failure remains reproducible. A final green report should not erase the fact that the same intended input produced inconsistent outcomes.
What changes when Pabot runs tests in parallel?
The official parallel-execution guide explains that Pabot normally splits at suite level and can split at test level. Separate processes do not provide one shared in-memory GLOBAL variable. Test-level splitting also changes how often suite fixtures may run across suite instances.
Use unique run-and-test namespaces for external resources. Prefer independent accounts or records where practical; allocate truly scarce resources through an explicit coordination mechanism. A suite setup that resets a common database can destroy another worker's work even though every worker has its own Python memory.
Do not equate parallel success with proof of independence. Process splitting might hide the in-memory list leak while exposing a filename collision. Compare serial ordered runs, selected tests, randomized runs and the intended parallel mode. The resulting failures point to different state layers.
This article's local demonstration did not run Pabot or a browser. Its narrower result is valuable: it reproduces one failure mechanism and verifies a fresh-object repair. The parallel recommendations are documentation-supported test-design guidance, not claimed execution results.
Practise explaining the ownership boundary
Answer with a concrete initial condition, operation, oracle, cleanup owner and failure artifact.
| Question | Robot Framework practice focus |
|---|---|
| Validate Unit-Test Coverage and Identify Missing Scenarios | Add partial-setup and shared-state cases rather than counting tests. |
| Implement a simple service with tests | Keep keyword contracts and assertions visible. |
| Build a Jenkins CI for graphics tests | Preserve artifacts and allocate scarce parallel resources. |
| Debug the Last-Element Random Allocation Case | Turn a nondeterministic symptom into a small reproducer. |
| Debug a Concurrent Job Scheduler | Explain cleanup racing with unfinished work. |
Robot Framework interview preparation is strongest when you can show why a test fails, not merely rename its steps. Use the QA and SDET guide to rehearse a release decision, then defend the isolation evidence behind that decision.
Sources and Further Reading
- Robot Framework User Guide
- Robot Framework BuiltIn library
- Robot Framework Collections library
- Robot Framework style guide
- Robot Framework: parallel execution with Pabot
- Selenium: avoid sharing state
Checked September 21, 2026. Local collection fixtures used Robot Framework 7.5. Library behavior and parallel-run configuration should be verified against the versions in your project.