Variables: Scalar, List, Dictionary, Environment, and Dynamic Values: Configuration, Design Patterns, and Trade-Offs

1. Start with ownership, not syntax

A variable mechanism is a design choice. Ask who owns the value, when it should change, whether callers should be able to override it, whether it is sensitive, and how long it should remain visible. Only then choose Variable section, variable file, CLI, environment, or runtime VAR.

2. Narrow scope is the default production pattern

Local variables are easiest to reason about because they cannot unexpectedly affect a later test. Test scope is appropriate for a correlation ID or fixture handle shared by keywords in one scenario. Suite scope can represent suite-owned setup state, but mutation affects later cases and therefore requires stronger teardown and ordering discipline. SUITES and GLOBAL expand the blast radius further.

Global scope is appropriate for truly global startup configuration, but runtime global mutation is rarely the cleanest way to communicate between test cases. Shared external stores or explicit return values usually make ownership clearer.

3. Variable section versus variable files

Variable sections are declarative and easy to review. Python variable files can return arbitrary objects and calculate values; YAML variable files need PyYAML and add a dependency. Dynamic power should be used where it solves a real configuration problem, not to hide initialization logic.

# variables/dev.py
STAGE = "dev"
BASE_URL = "http://127.0.0.1:8080"
LIMITS = {"workers": 2, "timeout": 5}

# run
python -m robot --variablefile variables/dev.py suites/

Keep paths relative to stable project structure rather than the caller’s accidental current directory. Use ${CURDIR} or a documented project-root convention when imports must be file-relative.

4. Mutable list/dict sharing: alias versus copy

Robot variables can hold real Python containers. If two variables refer to the same list or dictionary object, mutating through one reference changes the object seen through the other. Scope does not automatically clone the value.

*** Settings ***
Library    Collections

*** Test Cases ***
Aliasing Hazard
    VAR    @{base}      alpha    beta
    VAR    ${alias}     ${base}
    Append To List    ${alias}    gamma
    # ${base} now also refers to the mutated list object.

When independent state is required, create a copy with an appropriate collection/library mechanism instead of assuming assignment copied the container. In parallel suites, also remember that each worker process has its own Python memory while shared files/databases/services remain genuinely shared.

5. Convert at trust boundaries

A value supplied by CLI or environment is text unless converted. Convert where the suite first requires a semantic type. That gives failures a useful location and prevents subtle comparisons such as string "10" versus integer 10.

*** Variables ***
${DEFAULT_WORKERS: int}    2

*** Test Cases ***
Configuration Boundary
    VAR    ${workers: int}    %{RF_WORKERS=2}
    Should Be True    $workers > 0

Do not annotate every value. IDs, postal codes, version strings, and values with leading zeros may be intentionally textual even when they contain digits.

6. Secret-handling design

Secret conversion can reduce accidental exposure in Robot logs, but it does not solve acquisition, storage, rotation, authorization, or downstream-library logging. Keep the secret source outside committed files, convert to Secret early when compatible, and pass it only through APIs that preserve masking.

7. Naming conventions expose intended scope

The Robot Framework style guide recommends uppercase names for global and broader-scope variables and lowercase for local variables. This is convention, not parser enforcement, but it helps reviewers see whether a keyword is using local computation or wider configuration.

Context can override casing conventions when matching an external API schema is more readable. Consistency and ownership matter more than mechanically forcing every identifier into one shape.

8. Worked scenario: promotion across environments

9. Knowledge check

10. Summary and next step

Variable design is configuration architecture: narrow scopes reduce coupling, source choice communicates ownership, typed conversion belongs at semantic boundaries, mutable containers require explicit copying, and Secret is only one logging safeguard. Lesson 4 applies these rules to realistic failures and diagnosis.

Further reading

• Robot Framework 7.4.2 User Guide — Variables — scalar/list/dictionary/environment syntax, creation mechanisms, priorities, scopes, typed conversion, and Secret values.
• Robot Framework 7.4.2 User Guide — Variable priorities and scopes — static priority and runtime scope rules.
• Robot Framework 7.4.2 User Guide — VAR syntax — local/test/task/suite/suites/global scope configuration.
• Robot Framework 7.4.2 User Guide — Variable type conversion — stable typed variable creation introduced in 7.3.
• Robot Framework 7.4.2 User Guide — Secret variables — masking semantics and security limitations introduced in 7.4.
• Robot Framework Style Guide — casing and scope-oriented naming conventions.