Variables: Scalar, List, Dictionary, Environment, and Dynamic Values: Core Concepts and Mental Model

1. The practical problem: a value is not just a name

Chapter 05 gave user keywords explicit argument and return contracts. The next question is where their values come from. In a small suite, ${URL}, ${count}, and ${user} can look like simple placeholders. In a production suite, the same logical setting may exist in a Variable section, an imported resource, a Python variable file, a command-line option, an environment variable, a keyword argument, and a runtime VAR. If you do not know which source owns the value and how long it lives, a green local run can become a confusing CI failure.

Robot variables therefore need three separate questions: what object is the value?, which definition wins?, and where is that value visible? Type, priority, and scope answer those questions respectively. None of them automatically answers whether the value is safe to log, mutable, or appropriate to share across workers.

2. Four sigils, two different ideas

The symbols $, @, &, and % are syntax, not a complete type system. ${items} can hold a Python list and pass that list as one object. @{items} expands a list-like value into multiple cells/arguments. &{config} expands a dictionary into named arguments or mapping items where supported. %{NAME} reads an operating-system environment variable and always starts as a string.

*** Variables ***
${SERVICE}          inventory
@{REGIONS}          eu-west    us-east
&{LIMITS}           retries=3    timeout=5

*** Test Cases ***
Container versus expansion
    Log    ${REGIONS}        # one Python list object
    Log Many    @{REGIONS}   # two separate arguments/items
    Log    ${LIMITS}[timeout]
    Log    %{RF_STAGE=local}

The scalar syntax is the general “give me the object” form. List and dictionary syntax are useful when expanding the container. The environment syntax is a lookup into process environment state, not a Robot suite variable definition.

3. Sources have different owners

4. Priority: “first wins” before execution, “last visible definition wins” at runtime

For values established before execution, Robot Framework gives command-line variables the highest priority. An individual --variable overrides a command-line --variablefile. A Variable section in a suite overrides imported resource/variable-file values with the same name. Among imported static sources, import order matters.

Runtime values are different. A local keyword argument can shadow a suite variable while that keyword runs. A test-scoped value can shadow the same-named suite value during the test. When that narrower scope ends, the outer value becomes visible again. This is why “the variable was overwritten” is often the wrong diagnosis: it may only have been shadowed.

5. Scope is lifetime and visibility, not importance

VAR defaults to LOCAL. Robot Framework 7.4.2 also supports TEST (or TASK), SUITE, SUITES, and GLOBAL. Broader scope should be an explicit design decision because it increases the number of callers that can observe or mutate the state.

*** Test Cases ***
Scope tracing
    VAR    ${local}      local
    VAR    ${TEST}       test-value      scope=TEST
    VAR    ${SUITE}      suite-value     scope=SUITE
    Log    ${local}
    Log    ${TEST}
    Log    ${SUITE}

A global value is not “better configuration.” It is simply visible more widely. In parallel execution, suite/global mutation can also become a concurrency hazard because different workers do not share one magical in-memory namespace and external shared state may still race.

6. Typed variables: conversion happens when the variable is created

Robot Framework 7.3 introduced variable type conversion. In 7.4.2, a declaration such as ${PORT: int} asks Robot to convert the created value to an integer. The annotation is part of variable creation; it is not a permanent runtime type guard applied every time the variable is later used.

*** Variables ***
${PORT: int}        8080
${RATIO: float}     0.75
@{CODES: int}       200    201    204

*** Test Cases ***
Typed creation
    VAR    ${attempts: int}    3
    Should Be Equal    ${PORT}        ${8080}
    Should Be Equal    ${attempts}    ${3}

This matters most when configuration arrives as text. A command-line or environment value may need deliberate conversion before numeric comparison or arithmetic.

7. Secret is log protection, not encryption

Robot Framework 7.4 added the Secret type. A Secret wraps a confidential value so Robot Framework can avoid exposing the real value in its own logs when the object is passed between compatible keywords. The real value still exists in memory and is available through APIs or .value. External libraries can also disclose it if they unwrap or log it incorrectly.

*** Variables ***
${TOKEN: Secret}    %{RF_DEMO_TOKEN=FAKE_LOCAL_TOKEN}

*** Test Cases ***
Pass without revealing
    Log    ${TOKEN}    # Robot representation is masked
    # Do not use ${TOKEN.value} in normal test data; that exposes the value.

8. Why this matters in DevOps

CI pipelines often promote the same suite through local, integration, staging, and ephemeral review environments. Reproducibility depends on knowing whether a value came from committed test data, a command-line profile, an environment variable, a variable file, or runtime mutation. Provenance also helps incident response: if a test unexpectedly targeted staging, you need evidence of which source produced that value without dumping credentials into logs.

A strong operating model therefore treats variable sources as configuration interfaces. It records non-sensitive effective settings, keeps secrets out of ordinary logs, minimizes shared mutation, and uses narrow scopes by default.

9. Knowledge check

10. Summary and next step

Variables are values plus provenance, priority, and scope. Scalar/list/dictionary syntax determines how a value is passed; environment syntax reads process state; static and runtime definitions follow different resolution rules; typed creation can convert values; and Secret adds log masking without encryption. Lesson 2 turns this mental model into a controlled scope-tracing workflow.

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.