Rules list

This is the complete list of all Robocop rules grouped by categories. If you want to learn more about the rules and their features, see Rule basics.

There are over a 160 rules available in Robocop and they are organized into the following categories:

• ARG: Arguments

• COM: Comments

• DEPR: Deprecated code

• DOC: Documentation

• DUP: Duplications

• ERR: Errors

• IMP: Imports

• KW: Keywords

• LEN: Lengths

• MISC: Miscellaneous

• NAME: Naming

• ORD: Order

• SPC: Spacing

• TAG: Tags

• VAR: Variables

Below is the list of all Robocop rules.

Arguments

Rules for keyword arguments.

ARG01: unused-argument

Added in v3.2.0 ⦁ Supported RF versions: All

Message:

Keyword argument '{name}' is not used

Documentation:

Keyword argument was defined but not used:

*** Keywords ***
Keyword
    [Arguments]    ${used}    ${not_used}  # will report ${not_used}
    Log    ${used}
    IF    $used
        Log    Escaped syntax is supported.
    END

Keyword with ${embedded} and ${not_used}  # will report ${not_used}
    Log    ${embedded}

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

ARG02: argument-overwritten-before-usage

Added in v3.2.0 ⦁ Supported RF versions: All

Message:

Keyword argument '{name}' is overwritten before usage

Documentation:

Keyword argument was overwritten before it is used:

*** Keywords ***
Overwritten Argument
    [Arguments]    ${overwritten}  # we do not use ${overwritten} value at all
    ${overwritten}    Set Variable    value  # we only overwrite it

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

ARG03: undefined-argument-default

Added in v5.7.0 ⦁ Supported RF versions: All

Message:

Undefined argument default, use {arg_name}=${{EMPTY}} instead

Documentation:

Keyword arguments can define a default value. Every time you call the keyword, you can optionally overwrite this default.

When you use an argument default, you should be as clear as possible. This improves the readability of your code. The syntax ${argument}= is unclear unless you happen to know that it is technically equivalent to ${argument}=${EMPTY}. To prevent people from misreading your keyword arguments, explicitly state that the value is empty using the built-in ${EMPTY} variable.

Example of a rule violation:

*** Keywords ***
My Amazing Keyword
    [Arguments]    ${argument_name}=

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

ARG04: undefined-argument-value

Added in v5.7.0 ⦁ Supported RF versions: All

Message:

Undefined argument value, use {arg_name}=${{EMPTY}} instead

Documentation:

When calling a keyword, it can accept named arguments.

When you call a keyword, you should be as clear as possible. This improves the readability of your code. The syntax argument= is unclear unless you happen to know that it is technically equivalent to argument=${EMPTY}. To prevent people from misreading your keyword arguments, explicitly state that the value is empty using the built-in ${EMPTY} variable.

If your argument is falsely flagged by this rule, escape the = character in your argument value by like so: \=.

Example of a rule violation:

*** Test Cases ***
Test case
    My Amazing Keyword    argument_name=

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

ARG05: invalid-argument

Added in v1.11.0 ⦁ Supported RF versions: >=4.0

Message:

{error_msg}

Documentation:

Argument names should follow variable naming syntax: start with identifier ($, @ or &) and enclosed in curly brackets ({}).

Valid names:

*** Test Cases ***
Test case
    Keyword
        [Arguments]    ${var}    @{args}    &{config}    ${var}=default

Invalid names:

*** Test Cases ***
Test case
    Keyword
        [Arguments]    {var}    @args}    var=default

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

ARG06: duplicated-argument-name

Added in v1.11.0 ⦁ Supported RF versions: All

Message:

Argument name '{argument_name}' is already used

Documentation:

Argument name is already used.

Variable names in Robot Framework are case-insensitive and ignores spaces and underscores. Following arguments are duplicates:

*** Keywords ***
Keyword
    [Arguments]    ${var}  ${VAR}  ${v_ar}  ${v ar}
    Other Keyword

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

ARG07: arguments-per-line

Added in v\- ⦁ Supported RF versions: All

Message:

There is too many arguments per continuation line ({arguments_count} / {max_arguments_count})

Documentation:

Too many arguments per continuation line.

If the keyword’s [Arguments] are split into multiple lines, it is recommended to put only one argument per every line.

Incorrect code example:

*** Keywords ***
Keyword With Multiple Arguments
[Arguments]    ${first_arg}
...    ${second_arg}    ${third_arg}=default

Correct code:

*** Keywords ***
Keyword With Multiple Arguments
[Arguments]    ${first_arg}
...    ${second_arg}
...    ${third_arg}=default

Configurable parameters:

Name	Default value	Type	Description
severity	I	severity	Rule severity (E = Error, W = Warning, I = Info)
max_args	1	int	maximum number of arguments allowed in the continuation line

Comments

Rules for comments.

COM01: todo-in-comment

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Found a marker '{marker}' in the comments

Documentation:

TODO-like marker found in the comment.

By default, it reports TODO and FIXME markers.

Example:

# TODO: Refactor this code
# fixme

Configuration example:

robocop check --configure "todo-in-comment.markers=todo,Remove me,Fix this!"

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
markers	todo,fixme	comma separated value	List of case-insensitive markers that violate the rule in comments.

---

COM02: missing-space-after-comment

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Missing blank space after comment character

Documentation:

No space after the # character and comment body.

Comments usually starts from the new line, or after 2 spaces in the same line. ‘#’ characters denotes start of the comment, followed by the space and comment body:

# stand-alone comment
Keyword Call  # inline comment
### block comments are fine ###

Deviating from this pattern may lead to inconsistent or less readable comment format.

It is possible to configure block comments syntax that should be ignored. Configured regex for block comment should take into account the first character is #.

Example:

#bad
# good
### good block

Configuration example:

robocop check --configure missing-space-after-comment.block=^#[*]+

Allows commenting like:

#*****
#
# Important topics here!
#
#*****
or
#* Headers *#

Style guide:

• #comments

Configurable parameters:

Name	Default value	Type	Description
severity	I	severity	Rule severity (E = Error, W = Warning, I = Info)
block	^###	regex	Block comment regex pattern.

---

COM03: invalid-comment

Added in v1.0.0 ⦁ Supported RF versions: <4.0

Message:

Comment starts from the second character in the line

Documentation:

Invalid comment.

In Robot Framework 3.2.2 comments that started from second character in the line were not recognized as comments. ‘#’ characters needs to be in first or any other than second character in the line to be recognized as a comment.

Example:

# good
 # bad
  # third cell so it's good

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

COM04: ignored-data

Added in v1.3.0 ⦁ Supported RF versions: All

Message:

Ignored data found in file

Documentation:

Ignored data found in file.

All lines before first test data section (ref) are ignored. It’s recommended to add *** Comments *** section header for lines that should be ignored.

Missing section header:

Resource   file.resource  # it looks like *** Settings *** but section header is missing - line is ignored

*** Keywords ***
Keyword Name
   No Operation

Comment lines that should be inside *** Comments ***:

Deprecated Test
    Keyword
    Keyword 2

*** Test Cases ***

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

COM05: bom-encoding-in-file

Added in v1.7.0 ⦁ Supported RF versions: All

Message:

BOM (Byte Order Mark) found in the file

Documentation:

BOM (Byte Order Mark) found in the file.

Some code editors can save Robot file using BOM encoding. It is not supported by the Robot Framework. Ensure that file is saved in UTF-8 encoding.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

Deprecated code

Rules for deprecated code or code replacement recommendations.

DEPR01: if-can-be-used

Added in v1.4.0 ⦁ Supported RF versions: ==4.*

Message:

'{run_keyword}' can be replaced with IF block since Robot Framework 4.0

Documentation:

Run Keyword If or Run Keyword Unless used instead IF.

Starting from Robot Framework 4.0 IF block can be used instead of those keywords.

Incorrect code example:

*** Test Cases ***
Test case
    Run Keyword If    ${condition}    Keyword Call    ELSE    Log    Condition did not match.
    Run Keyword Unless    ${something_happened}    Assert Results

Correct code:

*** Test Cases ***
Test case
    IF    ${condition}
        Keyword Call
    ELSE
        Log    Condition did not match.
    END
    IF    not ${something_happened}
        Assert Results
    END

Configurable parameters:

Name	Default value	Type	Description
severity	I	severity	Rule severity (E = Error, W = Warning, I = Info)

---

DEPR02: deprecated-statement

Added in v2.0.0 ⦁ Supported RF versions: All

Message:

'{statement_name}' is deprecated since Robot Framework version {version}, use '{alternative}' instead

Documentation:

Statement is deprecated.

Detects any piece of code that is marked as deprecated but still works in RF.

For example, Run Keyword and Continue For Loop keywords or [Return] setting.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

DEPR03: deprecated-with-name

Added in v2.5.0 ⦁ Supported RF versions: >=6.0

Message:

Deprecated 'WITH NAME' alias marker used instead of 'AS'

Documentation:

Deprecated ‘WITH NAME’ alias marker used instead of ‘AS’.

WITH NAME marker that is used when giving an alias to an imported library is going to be renamed to AS. The motivation is to be consistent with Python that uses as for similar purpose.

Incorrect code example:

*** Settings ***
Library    Collections    WITH NAME    AliasedName

Correct code:

*** Settings ***
Library    Collections    AS    AliasedName

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

DEPR04: deprecated-singular-header

Added in v2.6.0 ⦁ Supported RF versions: >=6.0

Message:

'{singular_header}' deprecated singular header used instead of '{plural_header}'

Documentation:

Deprecated singlar header used instead of plurar form.

Robot Framework 6.0 starts deprecation period for singular headers forms. The rationale behind this change is available at https://github.com/robotframework/robotframework/issues/4431

Incorrect code example:

*** Setting ***
*** Keyword ***

Correct code:

*** Settings ***
*** Keywords ***

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

DEPR05: replace-set-variable-with-var

Added in v5.0.0 ⦁ Supported RF versions: >=7.0

Message:

{set_variable_keyword} used instead of VAR

Documentation:

Set X Variable used instead of VAR.

Starting from Robot Framework 7.0, it is possible to create variables inside tests and user keywords using the VAR syntax. The VAR syntax is recommended over previously existing keywords.

Incorrect code example:

*** Keywords ***
Set Variables To Different Scopes
    Set Local Variable    ${local}    value
    Set Test Variable    ${TEST_VAR}    value
    Set Task Variable    ${TASK_VAR}    value
    Set Suite Variable    ${SUITE_VAR}    value
    Set Global Variable    ${GLOBAL_VAR}    value

Correct code:

*** Keywords ***
Set Variables To Different Scopes
    VAR    ${local}    value
    VAR    ${TEST_VAR}    value    scope=TEST
    VAR    ${TASK_VAR}    value    scope=TASK
    VAR    ${SUITE_VAR}    value    scope=SUITE
    VAR    ${GLOBAL_VAR}    value    scope=GLOBAL

Configurable parameters:

Name	Default value	Type	Description
severity	I	severity	Rule severity (E = Error, W = Warning, I = Info)

---

DEPR06: replace-create-with-var

Added in v5.0.0 ⦁ Supported RF versions: >=7.0

Message:

{create_keyword} used instead of VAR

Documentation:

Create List/Dictionary used instead of VAR.

Starting from Robot Framework 7.0, it is possible to create variables inside tests and user keywords using the VAR syntax. The VAR syntax is recommended over previously existing keywords.

Incorrect code example:

*** Keywords ***
Create Variables
    @{list}    Create List    a  b
    &{dict}    Create Dictionary    key=value

Correct code:

*** Keywords ***
Create Variables
    VAR    @{list}    a  b
    VAR    &{dict}    key=value

Configurable parameters:

Name	Default value	Type	Description
severity	I	severity	Rule severity (E = Error, W = Warning, I = Info)

Documentation

Rules for documentation.

DOC01: missing-doc-keyword

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Missing documentation in '{name}' keyword

Documentation:

Keyword without documentation.

Keyword documentation is displayed in a tooltip in most code editors, so it is recommended to write it for each keyword.

You can add documentation to keyword using following syntax:

*** Keywords ***
Keyword
    [Documentation]  Keyword documentation
    Keyword Step
    Other Step

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

DOC02: missing-doc-test-case

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Missing documentation in '{name}' test case

Documentation:

Test case without documentation.

You can add documentation to test case using following syntax:

*** Test Cases ***
Test
    [Documentation]  Test documentation
    Keyword Step
    Other Step

The rule by default ignores templated test cases but it can be configured with:

robocop check --configure missing-doc-test-case.ignore_templated=False

Possible values are: Yes / 1 / True (default) or No / False / 0.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
ignore_templated	True	bool	whether templated tests should be documented or not

---

DOC03: missing-doc-suite

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Missing documentation in suite

Documentation:

Test suite without documentation.

You can add documentation to suite using following syntax:

*** Settings ***
Documentation    Suite documentation

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

DOC04: missing-doc-resource-file

Added in v2.8.0 ⦁ Supported RF versions: All

Message:

Missing documentation in resource file

Documentation:

Resource file without documentation.

You can add documentation to resource file using following syntax:

*** Settings ***
Documentation    Resource file documentation

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

Duplications

Rules for duplicated code such as settings or variables.

DUP01: duplicated-test-case

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Multiple test cases with name '{name}' (first occurrence in line {first_occurrence_line})

Documentation:

Multiple test cases with the same name in the suite.

It is not allowed to reuse the same name of the test case within the same suite in Robot Framework. Name matching is case-insensitive and ignores spaces and underscore characters.

Incorrect code example:

*** Test Cases ***
Test with name
    No Operation

test_with Name
    No Operation

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

DUP02: duplicated-keyword

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Multiple keywords with name '{name}' (first occurrence in line {first_occurrence_line})

Documentation:

Multiple keywords with the same name in the file.

Do not define keywords with the same name inside the same file. Name matching is case-insensitive and ignores spaces and underscore characters.

Incorrect code example:

*** Keywords ***
Keyword
    No Operation

keyword
    No Operation

K_eywor d
    No Operation

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

DUP03: duplicated-variable

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Multiple variables with name '{name}' in Variables section (first occurrence in line {first_occurrence_line})

Documentation:

Multiple variables with the same name in the file.

Variable names in Robot Framework are case-insensitive and ignore spaces and underscores. Following variables are duplicates:

*** Variables ***
${variable}    1
${VARIAble}    a
@{variable}    a  b
${v ariabl e}  c
${v_ariable}   d

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

DUP04: duplicated-resource

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Multiple resource imports with path '{name}' (first occurrence in line {first_occurrence_line})

Documentation:

Duplicated resource imports.

Avoid re-importing the same imports.

Incorrect code example:

*** Settings ***
Resource    path.resource
Resource    other_path.resource
Resource    path.resource

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

DUP05: duplicated-library

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Multiple library imports with name '{name}' and identical arguments (first occurrence in line {first_occurrence_line})

Documentation:

Duplicated library imports.

If you need to reimport library use alias:

*** Settings ***
Library  RobotLibrary
Library  RobotLibrary  AS  OtherRobotLibrary

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

DUP06: duplicated-metadata

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Duplicated metadata '{name}' (first occurrence in line {first_occurrence_line})

Documentation:

Duplicated metadata.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

DUP07: duplicated-variables-import

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Duplicated variables import with path '{name}' (first occurrence in line {first_occurrence_line})

Documentation:

Duplicated variables import.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

DUP08: section-already-defined

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

'{section_name}' section header already defined in file (first occurrence in line {first_occurrence_line})

Documentation:

Section header already defined in the file.

Duplicated section in the file. Robot Framework will handle repeated sections but it is recommended to not duplicate them.

Incorrect code example:

*** Test Cases ***
My Test
    Keyword

*** Keywords ***
Keyword
    No Operation

*** Test Cases ***  # duplicate
Other Test
    Keyword

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

DUP09: both-tests-and-tasks

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Both Task(s) and Test Case(s) section headers defined in file

Documentation:

Both Task(s) and Test Case(s) section headers defined in file.

The file contains both *** Test Cases *** and *** Tasks *** sections. Use only one of them.

*** Test Cases ***

*** Tasks ***

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

DUP10: duplicated-setting

Added in v2.0 ⦁ Supported RF versions: All

Message:

{error_msg}

Documentation:

Duplicated setting.

Some settings can be used only once in a file. Only the first value is used. Example:

*** Settings ***
Test Tags        F1
Test Tags        F2  # this setting will be ignored

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

Errors

Rules for syntax errors and critical issues with the code.

ERR01: parsing-error

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Robot Framework syntax error: {error_msg}

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

ERR03: missing-keyword-name

Added in v1.8.0 ⦁ Supported RF versions: All

Message:

Missing keyword name when calling some values

Documentation:

Missing keyword name.

Example of rule violation:

*** Keywords ***
Keyword
    ${var}
    ${one}      ${two}

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

ERR04: variables-import-with-args

Added in v1.11.0 ⦁ Supported RF versions: All

Message:

YAML variable files do not take arguments

Documentation:

YAML variables file import with arguments.

Example of rule violation:

*** Settings ***
Variables    vars.yaml        arg1
Variables    variables.yml    arg2
Variables    module           arg3  # valid from RF > 5

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

ERR05: invalid-continuation-mark

Added in v1.11.0 ⦁ Supported RF versions: All

Message:

Invalid continuation mark '{mark}'. It should be '...'

Documentation:

Invalid continuation mark.

Example of rule violation:

Keyword
..  ${var}  # .. instead of ...
...  1
....  2  # .... instead of ...

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

ERR08: non-existing-setting

Added in v1.11.0 ⦁ Supported RF versions: All

Message:

{error_msg}

Documentation:

Non-existing setting used in the code.

Example of rule violation:

*** Test Cases ***
Test case
    [Not Existing]  arg
    [Arguments]  ${arg}

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

ERR09: setting-not-supported

Added in v1.11.0 ⦁ Supported RF versions: All

Message:

Setting '[{setting_name}]' is not supported in {test_or_keyword}. Allowed are: {allowed_settings}

Documentation:

Not supported setting.

Following settings are supported in Test Case or Task:

*** Test Cases ***
Test case
    [Documentation]      Used for specifying a test case documentation.
    [Tags]               Used for tagging test cases.
    [Setup]              Used for specifying a test setup.
    [Teardown]       Used for specifying a test teardown.
    [Template]       Used for specifying a template keyword.
    [Timeout]        Used for specifying a test case timeout.

Following settings are supported in Keyword:

*** Keywords ***
Keyword
    [Documentation]      Used for specifying a user keyword documentation.
    [Tags]               Used for specifying user keyword tags.
    [Arguments]      Used for specifying user keyword arguments.
    [Return]         Used for specifying user keyword return values.
    [Teardown]       Used for specifying user keyword teardown.
    [Timeout]        Used for specifying a user keyword timeout.

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

ERR12: invalid-for-loop

Added in v1.0.0 ⦁ Supported RF versions: >=4.0

Message:

Invalid for loop syntax: {error_msg}

Documentation:

Invalid FOR loop syntax.

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

ERR13: invalid-if

Added in v1.0.0 ⦁ Supported RF versions: >=4.0

Message:

Invalid IF syntax: {error_msg}

Documentation:

Invalid IF syntax.

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

ERR14: return-in-test-case

Added in v2.0.0 ⦁ Supported RF versions: >=5.0

Message:

RETURN can only be used inside a user keyword

Documentation:

RETURN used outside user keyword.

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

ERR15: invalid-section-in-resource

Added in v3.1.0 ⦁ Supported RF versions: All

Message:

Resource file can't contain '{section_name}' section

Documentation:

Resource file with not supported section.

The higher-level structure of resource files is the same as that of test case files, but they can’t contain Test Cases or Tasks sections.

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

ERR16: invalid-setting-in-resource

Added in v3.3.0 ⦁ Supported RF versions: All

Message:

Settings section in resource file can't contain '{section_name}' setting

Documentation:

Not supported setting in *** Settings *** section in a resource file.

The Setting section in resource files can contain only import settings (Library, Resource, Variables), Documentation and Keyword Tags.

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

ERR17: unsupported-setting-in-init-file

Added in v3.3.0 ⦁ Supported RF versions: All

Message:

Setting '{setting}' is not supported in initialization files

Documentation:

Not supported setting in a initialization file.

Settings Default Tags and Test Template are not supported in initialization files.

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

Imports

Rules for resources, variables and libraries imports.

IMP01: wrong-import-order

Added in v1.7.0 ⦁ Supported RF versions: All

Message:

BuiltIn library import '{builtin_import}' should be placed before '{custom_import}'

Documentation:

Built-in imports placed after custom imports.

To make code more readable it needs to be more consistent. That’s why it is recommended to group known, built-in import before custom imports.

Example of rule violation:

*** Settings ***
Library    Collections
Library    CustomLibrary
Library    OperatingSystem  # BuiltIn library defined after custom CustomLibrary

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

IMP02: builtin-imports-not-sorted

Added in v5.2.0 ⦁ Supported RF versions: All

Message:

BuiltIn library import '{builtin_import}' should be placed before '{previous_builtin_import}'

Documentation:

Built-in imports are not sorted in a alphabetical order.

To increase readability sort the imports in a alphabetical order.

Example of rule violation:

*** Settings ***
Library    OperatingSystem
Library    Collections  # BuiltIn libraries imported not in alphabetical order

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

IMP03: non-builtin-imports-not-sorted

Added in v5.2.0 ⦁ Supported RF versions: All

Message:

Non builtin library import '{custom_import}' should be placed before '{previous_custom_import}'

Documentation:

Custom imports are not sorted in alphabetical order.

To increase readability sort the imports in alphabetical order. Beware that depending on your code, some of the custom imports may be depending on each other and the order of the imports.

Example of rule violation:

*** Settings ***
Library    Collections
Library    CustomLibrary
Library    AnotherCustomLibrary  # AnotherCustomLibrary library defined after custom CustomLibrary

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

IMP04: resources-imports-not-sorted

Added in v5.2.0 ⦁ Supported RF versions: All

Message:

Resource import '{resource_import}' should be placed before '{previous_resource_import}'

Documentation:

Resources imports are not sorted in a alphabetical order.

To increase readability sort the resources imports in a alphabetical order. Beware that depending on your code, some of the imports may be depending on each other and the order of the imports.

Example of rule violation:

*** Settings ***
Resource   CustomResource.resource
Resource   AnotherFile.resource

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

Keywords

Rules for keywords.

KW01: sleep-keyword-used

Added in v5.0.0 ⦁ Supported RF versions: All

Message:

Sleep keyword with '{duration_time}' sleep time found

Documentation:

Sleep keyword used.

Avoid using Sleep keyword in favour of polling.

For example:

*** Keywords ***
Add To Cart
    [Arguments]    ${item_name}
    Sleep    30s  # wait for page to load
    Element Should Be Visible    ${MAIN_HEADER}
    Click Element    //div[@name='${item_name}']/div[@id='add_to_cart']

Can be rewritten to:

*** Keywords ***
Add To Cart
    [Arguments]    ${item_name}
    Wait Until Element Is Visible    ${MAIN_HEADER}
    Click Element    //div[@name='${item_name}']/div[@id='add_to_cart']

It is also possible to report only if Sleep exceeds given time limit using max_time parameter:

robocop check -c sleep-keyword-used.max_time=1min .

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
max_time	0	timestr_to_secs	Maximum amount of time allowed in Sleep

---

KW02: not-allowed-keyword

Added in v5.1.0 ⦁ Supported RF versions: All

Message:

Keyword '{keyword}' is not allowed

Documentation:

Reports usage of not allowed keywords.

Configure which keywords should be reported by using keywords parameter. Keyword names are normalized to match Robot Framework search behaviour (lower case, removed whitespace and underscores).

For example:

> robocop check --select not-allowed-keyword -c not-allowed-keyword.keywords=click_using_javascript

*** Keywords ***
Keyword With Obsolete Implementation
    [Arguments]    ${locator}
    Click Using Javascript    ${locator}  # Robocop will report not allowed keyword

If keyword call contains possible library name (ie. Library.Keyword Name), Robocop checks if it matches the not allowed keywords and if not, it will remove library part and check again.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
keywords	None	comma_separated_list	Comma separated list of not allowed keywords

---

KW03: no-embedded-keyword-arguments

Added in v5.5.0 ⦁ Supported RF versions: All

Message:

Keyword with embedded arguments: {arguments}

Documentation:

Embedded arguments in keyword found.

Avoid using embedded arguments in keywords.

When using embedded keyword arguments, you mix what you do (the keyword name) with the data related to the action (the arguments). Mixing these two concepts can create hard-to-understand code, which can result in mistakes in your test code.

Embedded keyword arguments can also make it hard to understand which keyword you’re using. Sometimes even Robotframework gets confused when naming conflicts occur. There are ways to fix naming conflicts, but this adds unnecessary complexity to your keyword.

To prevent these issues, use normal arguments instead.

Example: Using a keyword with one embedded argument. Buying the drink and the size of the drink are jumbled together:

*** Test Cases ***
Prepare for an amazing movie
    Buy a large soda

*** Keywords ***
Buy a ${size} soda
    # Do something wonderful

Change the embedded argument to a normal argument. Now buying the drink is separate from the size of the drink. In this approach, it’s easier to see that you can change the size of your drink:

*** Test Cases ***
Prepare for an amazing movie
    Buy a soda    size=large

*** Keywords ***
Buy a soda
    [Arguments]    ${size}
    # Do something wonderful

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

KW04: unused-keyword

Warning

Rule is deprecated.

Added in v5.3.0 ⦁ Supported RF versions: All

Message:

Keyword '{keyword_name}' is not used

Documentation:

Keyword is not used.

Reports not used keywords.

Example:

*** Test Cases ***
Test that only non used keywords are reported
    Used Keyword

*** Keywords ***
Not Used Keyword  # this keyword will be reported as not used
    [Arguments]    ${arg}
    Should Be True    ${arg}>50

Rule is under development - may report false negatives or positives. Currently it does only support keywords from suites and private keywords. If the keyword is called dynamically (for example through variable) it will be not detected as used.

Configurable parameters:

Name	Default value	Type	Description
severity	I	severity	Rule severity (E = Error, W = Warning, I = Info)

Lengths

Rules for lengths, such as length of the test case or the file.

LEN01: too-long-keyword

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Keyword '{keyword_name}' is too long ({keyword_length}/{allowed_length})

Documentation:

Keyword is too long.

Avoid too long keywords for readability and maintainability.

Severity thresholds

This rule supports dynamic severity configurable using thresholds (Severity threshold). Parameter max_len will be used to determine issue severity depending on the thresholds.

When configuring thresholds remember to also set max_len - its value should be lower or equal to the lowest value in the threshold.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
max_len	40	int	number of lines allowed in a keyword
ignore_docs	False	bool	Ignore documentation

---

LEN02: too-few-calls-in-keyword

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Keyword '{keyword_name}' has too few keywords inside ({keyword_count}/{min_allowed_count})

Documentation:

Too few keyword calls in keyword.

Consider if the custom keyword is required at all.

Incorrect code example:

*** Test Cases ***
Test
    Thin Wrapper

*** Keywords ***
Thin Wrapper
    Other Keyword    ${arg}

Correct code example:

*** Test Cases ***
Test
    Other Keyword    ${arg}

Severity thresholds

This rule supports dynamic severity configurable using thresholds (Severity threshold). Parameter min_calls will be used to determine issue severity depending on the thresholds.

When configuring thresholds remember to also set min_calls - its value should be lower or equal to the lowest value in the threshold.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
min_calls	1	int	number of keyword calls required in a keyword

---

LEN03: too-many-calls-in-keyword

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Keyword '{keyword_name}' has too many keywords inside ({keyword_count}/{max_allowed_count})

Documentation:

Too many keyword calls in keyword.

Avoid too long keywords for readability and maintainability.

Severity thresholds

This rule supports dynamic severity configurable using thresholds (Severity threshold). Parameter max_calls will be used to determine issue severity depending on the thresholds.

When configuring thresholds remember to also set max_calls - its value should be lower or equal to the lowest value in the threshold.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
max_calls	10	int	number of keyword calls allowed in a keyword

---

LEN04: too-long-test-case

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Test case '{test_name}' is too long ({test_length}/{allowed_length})

Documentation:

Test case is too long.

Avoid too long test cases for readability and maintainability.

Severity thresholds

This rule supports dynamic severity configurable using thresholds (Severity threshold). Parameter max_len will be used to determine issue severity depending on the thresholds.

When configuring thresholds remember to also set max_len - its value should be lower or equal to the lowest value in the threshold.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
max_len	20	int	number of lines allowed in a test case
ignore_docs	False	bool	Ignore documentation

---

LEN05: too-few-calls-in-test-case

Added in v2.4.0 ⦁ Supported RF versions: All

Message:

Test case '{test_name}' has too few keywords inside ({keyword_count}/{min_allowed_count})

Documentation:

Too few keyword calls in test cases.

Test without keywords will fail. Add more keywords or set results using Fail, Pass Execution or Skip keywords:

*** Test Cases ***
Test case
    [Tags]    smoke
    Skip    Test case draft

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)
min_calls	1	int	number of keyword calls required in a test case
ignore_templated	False	bool	Ignore templated tests

---

LEN06: too-many-calls-in-test-case

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Test case '{test_name}' has too many keywords inside ({keyword_count}/{max_allowed_count})

Documentation:

Too many keyword calls in test case.

Redesign the test and move complex logic to separate keywords to increase readability.

Severity thresholds

This rule supports dynamic severity configurable using thresholds (Severity threshold). Parameter max_calls will be used to determine issue severity depending on the thresholds.

When configuring thresholds remember to also set max_calls - its value should be lower or equal to the lowest value in the threshold.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
max_calls	10	int	number of keyword calls allowed in a test case
ignore_templated	False	bool	Ignore templated tests

---

LEN07: too-many-arguments

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Keyword '{keyword_name}' has too many arguments ({arguments_count}/{max_allowed_count})

Documentation:

Keyword has too many arguments.

Style guide:

• #arguments

Severity thresholds

This rule supports dynamic severity configurable using thresholds (Severity threshold). Parameter max_args will be used to determine issue severity depending on the thresholds.

When configuring thresholds remember to also set max_args - its value should be lower or equal to the lowest value in the threshold.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
max_args	5	int	number of lines allowed in a file

---

LEN08: line-too-long

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Line is too long ({line_length}/{allowed_length})

Documentation:

Line is too long.

It is possible to ignore lines that match regex pattern. Configure it using following option:

robocop check --configure line-too-long.ignore_pattern=pattern

The default pattern is https?://\\S+ that ignores the lines that look like an URL.

Style guide:

• #line-length

Severity thresholds

This rule supports dynamic severity configurable using thresholds (Severity threshold). Parameter line_length will be used to determine issue severity depending on the thresholds.

When configuring thresholds remember to also set line_length - its value should be lower or equal to the lowest value in the threshold.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
line_length	120	int	number of characters allowed in line
ignore_pattern	re.compile('https?://\\S+')	regex	ignore lines that contain configured pattern

---

LEN09: empty-section

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Section '{section_name}' is empty

Documentation:

Section is empty.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

LEN10: number-of-returned-values

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Too many return values ({return_count}/{max_allowed_count})

Documentation:

Too many return values.

Severity thresholds

This rule supports dynamic severity configurable using thresholds (Severity threshold). Parameter max_returns will be used to determine issue severity depending on the thresholds.

When configuring thresholds remember to also set max_returns - its value should be lower or equal to the lowest value in the threshold.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
max_returns	4	int	allowed number of returned values from a keyword

---

LEN11: empty-metadata

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Metadata settings does not have any value set

Documentation:

Metadata settings does not have any value set.

Incorrect code example:

*** Settings ***
Metadata

Correct code example:

*** Settings ***
Metadata    Platform    ${PLATFORM}

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

LEN12: empty-documentation

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Documentation of {block_name} is empty

Documentation:

Documentation is empty.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

LEN13: empty-force-tags

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Force Tags are empty

Documentation:

Force Tags are empty.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

LEN14: empty-default-tags

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Default Tags are empty

Documentation:

Default Tags are empty.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

LEN15: empty-variables-import

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Import variables path is empty

Documentation:

Import variables path is empty.

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

LEN16: empty-resource-import

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Import resource path is empty

Documentation:

Import resources path is empty.

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

LEN17: empty-library-import

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Import library path is empty

Documentation:

Import library path is empty.

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

LEN18: empty-setup

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Setup of {block_name} does not have any keywords

Documentation:

Empty setup.

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

LEN19: empty-suite-setup

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Suite Setup does not have any keywords

Documentation:

Empty Suite Setup.

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

LEN20: empty-test-setup

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Test Setup does not have any keywords

Documentation:

Empty Test Setup.

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

LEN21: empty-teardown

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Teardown of {block_name} does not have any keywords

Documentation:

Empty Teardown.

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

LEN22: empty-suite-teardown

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Suite Teardown does not have any keywords

Documentation:

Empty Suite Teardown.

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

LEN23: empty-test-teardown

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Test Teardown does not have any keywords

Documentation:

Empty Test Teardown.

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

LEN24: empty-timeout

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Timeout of {block_name} is empty

Documentation:

Empty Timeout.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

LEN25: empty-test-timeout

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Test Timeout is empty

Documentation:

Empty Test Timeout.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

LEN26: empty-arguments

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Arguments of {block_name} are empty

Documentation:

Empty [Arguments] setting.

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

LEN27: too-many-test-cases

Added in v1.10.0 ⦁ Supported RF versions: All

Message:

Too many test cases ({test_count}/{max_allowed_count})

Documentation:

Too many test cases.

Severity thresholds

This rule supports dynamic severity configurable using thresholds (Severity threshold). Parameter max_testcases or max_templated_testcases will be used to determine issue severity depending on the thresholds.

When configuring thresholds remember to also set max_testcases or max_templated_testcases - its value should be lower or equal to the lowest value in the threshold.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
max_testcases	50	int	number of test cases allowed in a suite
max_templated_testcases	100	int	number of test cases allowed in a templated suite

---

LEN28: file-too-long

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

File has too many lines ({lines_count}/{max_allowed_count})

Documentation:

File has too many lines.

Severity thresholds

This rule supports dynamic severity configurable using thresholds (Severity threshold). Parameter max_lines will be used to determine issue severity depending on the thresholds.

When configuring thresholds remember to also set max_lines - its value should be lower or equal to the lowest value in the threshold.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
max_lines	400	int	number of lines allowed in a file

---

LEN29: empty-test-template

Added in v3.1.0 ⦁ Supported RF versions: All

Message:

Test Template is empty

Documentation:

Test Template is empty.

Test Template sets the template to all tests in a suite. Empty value is considered an error because it leads the users to wrong impression on how the suite operates. Without value, the setting is ignored and the tests are not templated.

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

LEN30: empty-template

Added in v3.1.0 ⦁ Supported RF versions: All

Message:

Template of {block_name} is empty. To overwrite suite Test Template use more explicit [Template]  NONE

Documentation:

[Template] is empty.

The [Template] setting overrides the possible template set in the Setting section, and an empty value for [Template] means that the test has no template even when Test Template is used.

If it is intended behaviour, use more explicit NONE value to indicate that you want to overwrite suite Test Template:

*** Settings ***
Test Template    Template Keyword

*** Test Cases ***
Templated test
    argument

Not templated test
    [Template]    NONE

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

LEN31: empty-keyword-tags

Added in v3.3.0 ⦁ Supported RF versions: >=6

Message:

Keyword Tags are empty

Documentation:

Keyword Tags are empty.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

Miscellaneous

Miscellaneous rules.

MISC01: keyword-after-return

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

{error_msg}

Documentation:

Keyword call after [Return] setting.

To improve readability use [Return] setting at the end of the keyword. If you want to return immediately from the keyword, use RETURN statement instead. [Return] does not return from the keyword but only sets the values that will be returned at the end of the keyword.

Incorrect code example:

*** Keywords ***
Keyword
    Step
    [Return]    ${variable}
    ${variable}    Other Step

Correct code:

*** Keywords ***
Keyword
    Step
    ${variable}    Other Step
    [Return]    ${variable}

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

MISC02: empty-return

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

[Return] is empty

Documentation:

[Return] is empty.

[Return] statement is used to define variables returned from keyword. If you don’t return anything from keyword, don’t use [Return].

Incorrect code example:

*** Keywords ***
Keyword
    Gather Results
    Assert Results
    [Return]

Correct code:

*** Keywords ***
Keyword
    Gather Results
    Assert Results

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

MISC03: nested-for-loop

Added in v1.0.0 ⦁ Supported RF versions: <4.0

Message:

Not supported nested for loop

Documentation:

Not supported nested for loop.

Older versions of Robot Framework did not support nested for loops:

*** Test Cases
Test case
    FOR    ${var}    IN RANGE    10
        FOR   ${other_var}   IN    a  b
            # Nesting supported from Robot Framework 4.0+
        END
    END

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

MISC04: inconsistent-assignment

Added in v1.7.0 ⦁ Supported RF versions: All

Message:

The assignment sign is not consistent within the file. Expected '{expected_sign}' but got '{actual_sign}' instead

Documentation:

Not consistent assignment sign in the file.

Use only one type of assignment sign in a file.

Incorrect code example:

*** Keywords ***
Keyword
    ${var} =  Other Keyword
    No Operation

Keyword 2
    No Operation
    ${var}  ${var2}    Some Keyword

Correct code:

*** Keywords ***
Keyword
    ${var}    Other Keyword
    No Operation

Keyword 2
    No Operation
    ${var}  ${var2}    Some Keyword

By default, Robocop looks for most popular assignment sign in the file. It is possible to define expected assignment sign by running:

Cli

robocop check --configure inconsistent-assignment.assignment_sign_type=none

Configuration file

[tool.robocop.lint]
configure = [
    "inconsistent-assignment.assignment_sign_type=none"
]

You can choose between following assignment signs:

• ‘autodetect’ (default),

• ‘none’,

• ‘equal_sign’ (=)

• ‘space_and_equal_sign’ (`` =``).

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
assignment_sign_type	autodetect	assignment sign type	possible values: ‘autodetect’ (default), ‘none’ (‘’), ‘equal_sign’ (‘=’) or space_and_equal_sign (’ =’)

---

MISC05: inconsistent-assignment-in-variables

Added in v1.7.0 ⦁ Supported RF versions: All

Message:

The assignment sign is not consistent inside the variables section. Expected '{expected_sign}' but got '{actual_sign}' instead

Documentation:

Not consistent assignment sign in the *** Variables *** section.

Use one type of assignment sign in Variables section.

Incorrect code example:

*** Variables ***
${var} =    1
${var2}=    2
${var3} =   3
${var4}     a
${var5}     b

Correct code:

*** Variables ***
${var}      1
${var2}     2
${var3}     3
${var4}     a
${var5}     b

By default, Robocop looks for the most popular assignment sign in the file. It is possible to define expected assignment sign by running:

robocop check --configure inconsistent-assignment-in-variables.assignment_sign_type=equal_sign

You can choose between following signs:

• ‘autodetect’ (default),

• ‘none’,

• ‘equal_sign’ (=)

• ‘space_and_equal_sign’ (`` =``).

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
assignment_sign_type	autodetect	assignment sign type	possible values: ‘autodetect’ (default), ‘none’ (‘’), ‘equal_sign’ (‘=’) or space_and_equal_sign (’ =’)

---

MISC06: can-be-resource-file

Added in v1.10.0 ⦁ Supported RF versions: All

Message:

No tests in '{file_name}' file, consider renaming to '{file_name_stem}.resource'

Documentation:

No tests in the file, consider renaming file extension to .resource.

If the Robot file contains only keywords or variables, it’s a good practice to use .resource extension.

Configurable parameters:

Name	Default value	Type	Description
severity	I	severity	Rule severity (E = Error, W = Warning, I = Info)

---

MISC07: if-can-be-merged

Added in v2.0.0 ⦁ Supported RF versions: >=4.0

Message:

IF statement can be merged with previous IF (defined in line {line})

Documentation:

IF statement can be merged with previous IF.

IF statement follows another IF with identical conditions. It can be possibly merged into one.

Example of rule violation:

*** Test Cases ***
Test case
    IF  ${var} == 4
        Keyword
    END
    # comments are ignored
    IF  ${var}  == 4
        Keyword 2
    END

IF statement is considered identical only if all branches have identical conditions.

Similar but not identical IF:

*** Test Cases ***
Test case
    IF  ${variable}
        Keyword
    ELSE
        Other Keyword
    END
    IF  ${variable}
        Keyword
    END

Configurable parameters:

Name	Default value	Type	Description
severity	I	severity	Rule severity (E = Error, W = Warning, I = Info)

---

MISC08: statement-outside-loop

Added in v2.0.0 ⦁ Supported RF versions: >=5.0

Message:

{name} {statement_type} used outside a loop

Documentation:

Loop statement used outside loop.

Following keywords and statements should only be used inside loop (WHILE or FOR):

• Exit For Loop

• Exit For Loop If

• Continue For Loop

• Continue For Loop If

• CONTINUE

• BREAK

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

MISC09: inline-if-can-be-used

Added in v2.0.0 ⦁ Supported RF versions: >=5.0

Message:

IF can be replaced with inline IF

Documentation:

IF can be replaced with inline IF.

Short and simple IF statements can be replaced with inline IF.

Following IF:

IF    $condition
    BREAK
END

can be replaced with:

IF    $condition    BREAK

Severity thresholds

This rule supports dynamic severity configurable using thresholds (Severity threshold). Parameter max_width will be used to determine issue severity depending on the thresholds.

When configuring thresholds remember to also set max_width - its value should be lower or equal to the lowest value in the threshold.

Configurable parameters:

Name	Default value	Type	Description
severity	I	severity	Rule severity (E = Error, W = Warning, I = Info)
max_width	80	int	maximum width of IF (in characters) below which it will be recommended to use inline IF

---

MISC10: unreachable-code

Added in v3.1.0 ⦁ Supported RF versions: >=5.0

Message:

Unreachable code after {statement} statement

Documentation:

Unreachable code.

Detects the unreachable code after RETURN, BREAK or CONTINUE statements.

For example:

*** Keywords ***
Example Keyword
    FOR    ${animal}    IN    cat    dog
        IF    '${animal}' == 'cat'
            CONTINUE
            Log  ${animal}  # unreachable log
        END
        BREAK
        Log    Unreachable log
    END
    RETURN
    Log    Unreachable log

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

MISC11: multiline-inline-if

Added in v3.1.0 ⦁ Supported RF versions: >=5.0

Message:

Inline IF split to multiple lines

Documentation:

Multi-line inline IF.

It’s allowed to create inline IF that spans multiple lines, but it should be avoided, since it decreases readability. Try to use normal IF/ELSE instead.

Incorrect code example:

*** Keywords ***
Keyword
    IF  ${condition}  Log  hello
    ...    ELSE       Log  hi!

Correct code:

*** Keywords ***
Keyword
    IF  ${condition}    Log  hello     ELSE    Log  hi!

or IF block can be used:

*** Keywords ***
Keyword
    IF  ${condition}
        Log  hello
    ELSE
        Log  hi!
    END

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

MISC12: unnecessary-string-conversion

Added in v4.0.0 ⦁ Supported RF versions: >=4.0

Message:

Variable '{name}' in '{block_name}' condition has unnecessary string conversion

Documentation:

# TODO: Not used atm, see if it was deprecated before Variable in condition has unnecessary string conversion.

Expressions in Robot Framework are evaluated using Python’s eval function. When a variable is used in the expression using the normal ${variable} syntax, its value is replaced before the expression is evaluated. For example, with the following expression:

*** Test Cases ***
Check if schema was uploaded
    Upload Schema    schema.avsc
    Check If File Exist In SFTP    schema.avsc

*** Keywords ***
Upload Schema
    [Arguments]    ${filename}
    IF    ${filename} == 'default'
        ${filename}    Get Default Upload Path
    END
    Send File To SFTP Root   ${filename}

“${filename}” will be replaced by “schema.avsc”:

IF    schema.avsc == 'default'

“schema.avsc” will not be recognized as Python variable. That’s why you need to quote it:

IF    '${filename}' == 'default'

However it introduces unnecessary string conversion and can mask difference in the type. For example:

${numerical}    Set Variable    10  # ${numerical} is actually string 10, not integer 10
IF    "${numerical}" == "10"

You can use $variable syntax instead:

IF    $numerical == 10

It will put the actual variable in the evaluated expression without converting it to string.

Configurable parameters:

Name	Default value	Type	Description
severity	I	severity	Rule severity (E = Error, W = Warning, I = Info)

---

MISC13: expression-can-be-simplified

Added in v4.0.0 ⦁ Supported RF versions: >=4.0

Message:

'{block_name}' condition can be simplified

Documentation:

Condition can be simplified.

Evaluated expression can be simplified.

Incorrect code example:

*** Keywords ***
Click On Element
    [Arguments]    ${locator}
    IF    ${is_element_visible}==${TRUE}    RETURN
    ${is_element_enabled}    Set Variable    ${TRUE}
    WHILE    ${is_element_enabled} != ${TRUE}
        ${is_element_enabled}    Get Element Status    ${locator}
    END
    Click    ${locator}

Correct code:

*** Keywords ***
Click On Element
    [Arguments]    ${locator}
    IF    ${is_element_visible}    RETURN
    ${is_element_enabled}    Set Variable    ${FALSE}
    WHILE    not ${is_element_enabled}
        ${is_element_enabled}    Get Element Status    ${locator}
    END
    Click    ${locator}

Comparisons to empty sequences (lists, dicts, sets), empty string or 0 can be also simplified:

*** Test Cases ***
Check conditions
    Should Be True     ${list} == []  # equivalent of 'not ${list}'
    Should Be True     ${string} != ""  # equivalent of '${string}'
    Should Be True     len(${sequence}))  # equivalent of '${sequence}'

Configurable parameters:

Name	Default value	Type	Description
severity	I	severity	Rule severity (E = Error, W = Warning, I = Info)

---

MISC14: misplaced-negative-condition

Added in v4.0.0 ⦁ Supported RF versions: >=4.0

Message:

'{block_name}' condition '{original_condition}' can be rewritten to '{proposed_condition}'

Documentation:

Position of not operator can be changed for better readability.

Incorrect code example:

*** Keywords ***
Check Unmapped Codes
    ${codes}    Get Codes From API
    IF    not ${codes} is None
        FOR    ${code}    IN    @{codes}
            Validate Single Code    ${code}
        END
    ELSE
        Fail    Did not receive codes from API.
    END

Correct code:

*** Keywords ***
Check Unmapped Codes
    ${codes}    Get Codes From API
    IF    ${codes} is not None
        FOR    ${code}    IN    @{codes}
            Validate Single Code    ${code}
        END
    ELSE
        Fail    Did not receive codes from API.
    END

Configurable parameters:

Name	Default value	Type	Description
severity	I	severity	Rule severity (E = Error, W = Warning, I = Info)

Naming

Naming rules.

NAME01: not-allowed-char-in-name

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Not allowed character '{character}' found in {block_name} name

Documentation:

Not allowed character found.

Reports not allowed characters found in Test Case or Keyword names. By default it’s a dot (.). You can configure what patterns are reported by calling:

robocop check --configure not-allowed-char-in-name.pattern=regex_pattern

regex_pattern should define regex pattern not allowed in names. For example [@\[] pattern would report any occurrence of @[ characters.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
pattern	re.compile('[\\.\\?]')	regex	pattern defining characters (not) allowed in a name

---

NAME02: wrong-case-in-keyword-name

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Keyword name '{keyword_name}' does not follow case convention

Documentation:

Keyword name does not follow case convention.

Keyword names need to follow a specific case convention. The convention can be set using convention parameter and accepts one of the 2 values: each_word_capitalized or first_word_capitalized.

By default, it’s configured to each_word_capitalized, which requires each keyword to follow such convention:

*** Keywords ***
Fill Out The Form
    Provide Shipping Address
    Provide Payment Method
    Click 'Next' Button
    [Teardown]  Log Form Data

You can also set it to first_word_capitalized which requires first word to have first letter capital:

*** Keywords ***
Fill out the form
    Provide shipping address
    Provide payment method
    Click 'Next' button
    [Teardown]  Log form data

The rule also accepts another parameter pattern which can be used to configure words that are accepted in the keyword name, even though they violate the case convention.

pattern parameter accepts a regex pattern. For example, configuring it to robocop\.readthedocs\.io would make such keyword legal:

Go To robocop.readthedocs.io Page

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
convention	each_word_capitalized	str	possible values: ‘each_word_capitalized’ (default) or ‘first_word_capitalized’
pattern	re.compile('')	regex	pattern for accepted words in keyword

---

NAME03: keyword-name-is-reserved-word

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

'{keyword_name}' is a reserved keyword{error_msg}

Documentation:

Keyword name is a reserved word.

Do not use reserved names for keyword names. Following names are reserved:

• IF

• ELSE IF

• ELSE

• FOR

• END

• WHILE

• CONTINUE

• RETURN

• TRY

• EXCEPT

• FINALLY

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

NAME04: underscore-in-keyword-name

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Underscores in keyword name '{keyword_name}'

Documentation:

Underscores in keyword name.

You can replace underscores with spaces.

Incorrect code example:

keyword_with_underscores

Correct code:

Keyword Without Underscores

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

NAME05: setting-name-not-in-title-case

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Setting name '{setting_name}' not in title or uppercase

Documentation:

Setting name not in title or upper case.

Incorrect code example:

*** Settings ***
resource    file.resource

*** Test Cases ***
Test
    [documentation]  Some documentation
    Step

Correct code:

*** Settings ***
Resource    file.resource

*** Test Cases ***
Test
    [DOCUMENTATION]  Some documentation
    Step

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

NAME06: section-name-invalid

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Section name should be in format '{section_title_case}' or '{section_upper_case}'

Documentation:

Section name does not follow convention.

Section name should use Title Case or CAP CASE case convention.

Incorrect code example:

*** settings ***
*** KEYwords ***

Correct code:

*** SETTINGS ***
*** Keywords ***

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

NAME07: not-capitalized-test-case-title

Added in v1.4.0 ⦁ Supported RF versions: All

Message:

Test case '{test_name}' title does not start with capital letter

Documentation:

Test case title does not start with capital letter.

Incorrect code example:

*** Test Cases ***
validate user details

Correct code example:

*** Test Cases ***
Validate user details

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

NAME08: section-variable-not-uppercase

Added in v1.4.0 ⦁ Supported RF versions: All

Message:

Section variable '{variable_name}' name is not uppercase

Documentation:

Section variable name is not uppercase.

Incorrect code example:

*** Variables ***
${section_variable}    value

Correct code:

*** Variables ***
${SECTION_VARIABLE}    value

Style guide:

• #variables-section

• #variable-scope-and-casing

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

NAME09: else-not-upper-case

Added in v1.5.0 ⦁ Supported RF versions: All

Message:

ELSE and ELSE IF is not uppercase

Documentation:

ELSE and ELSE IF is not uppercase.

Incorrect code example:

*** Keywords ***
Describe Temperature
    [Arguments]     ${degrees}
    If         ${degrees} > ${30}
        RETURN  Hot
    else if    ${degrees} > ${15}
        RETURN  Warm
    Else
        RETURN  Cold

Correct code:

*** Keywords ***
Describe Temperature
    [Arguments]     ${degrees}
    IF         ${degrees} > ${30}
        RETURN  Hot
    ELSE IF    ${degrees} > ${15}
        RETURN  Warm
    ELSE
        RETURN  Cold

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

NAME10: keyword-name-is-empty

Added in v1.8.0 ⦁ Supported RF versions: All

Message:

Keyword name is empty

Documentation:

Keyword name is empty.

Remember to always add a keyword name and avoid such code:

*** Keywords ***
# no keyword name here!!!
    Log To Console  hi

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

NAME11: test-case-name-is-empty

Added in v1.8.0 ⦁ Supported RF versions: All

Message:

Test case name is empty

Documentation:

Test case name is empty.

Remember to always add a test case name and avoid such code:

*** Test Cases ***
# no test case name here!!!
    Log To Console  hello

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

NAME12: empty-library-alias

Added in v1.10.0 ⦁ Supported RF versions: All

Message:

Library alias is empty

Documentation:

Library alias is empty.

Use non-empty name when using library import with alias.

Incorrect code example:

*** Settings ***
Library  CustomLibrary  AS

Correct code:

*** Settings ***
Library  CustomLibrary  AS  AnotherName

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

NAME13: duplicated-library-alias

Added in v1.10.0 ⦁ Supported RF versions: All

Message:

Library alias is the same as original name

Documentation:

Library alias is the same as original name.

Examples of rule violation:

*** Settings ***
Library  CustomLibrary  AS  CustomLibrary   # same as library name
Library  CustomLibrary  AS  Custom Library  # same as library name (spaces are ignored)

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

NAME14: bdd-without-keyword-call

Added in v1.11.0 ⦁ Supported RF versions: All

Message:

BDD reserved keyword '{keyword_name}' not followed by any keyword{error_msg}

Documentation:

BDD keyword not followed by any keyword.

When using BDD reserved keywords (such as GIVEN, WHEN, AND, BUT or THEN) use them together with name of the keyword to run.

Incorrect code example:

*** Test Cases ***
Test case
    Given
    When User Log In
    Then User Should See Welcome Page

Correct code:

*** Test Cases ***
Test case
    Given Setup Is Complete
    When User Log In
    Then User Should See Welcome Page

Since those words are used for BDD style, it’s also recommended not to use them within the user keyword name.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

NAME15: not-allowed-char-in-filename

Added in v2.1.0 ⦁ Supported RF versions: All

Message:

Not allowed character '{character}' found in {block_name} name

Documentation:

Not allowed character found in filename.

Reports not allowed pattern found in Suite names. By default, it’s a dot (.). You can configure what characters are reported by running:

robocop check --configure not-allowed-char-in-filename.pattern=regex_pattern .

where regex_pattern should define regex pattern for characters not allowed in names. For example [@[] pattern would report any occurrence of @[ characters.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
pattern	re.compile('[\\.\\?]')	regex	pattern defining characters (not) allowed in a name

---

NAME16: invalid-section

Added in v3.2.0 ⦁ Supported RF versions: >=6.1

Message:

Invalid section '{invalid_section}'

Documentation:

Invalid section found.

Robot Framework 6.1 detects unrecognized sections based on the language defined for the specific files. Consider using --language parameter if the file is defined with different language.

It is also possible to configure language in the file:

language: pl

*** Przypadki Testowe ***
Wypisz dyrektywę 4
    Log   Błąd dostępu

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

NAME17: mixed-task-test-settings

Added in v3.3.0 ⦁ Supported RF versions: All

Message:

Use {task_or_test}-related setting '{setting}' if {tasks_or_tests} section is used

Documentation:

Task related setting used with *** Test Cases *** or Test related setting used with *** Tasks *** section.

If *** Tasks *** section is present in the file, use task-related settings like Task Setup, Task Teardown, Task Template, Task Tags and Task Timeout instead of their Test variants.

Similarly, use test-related settings when using *** Test Cases *** section.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

Order

Ordering rules.

ORD01: test-case-section-out-of-order

Added in v5.3.0 ⦁ Supported RF versions: All

Message:

'{section_name}' is in wrong place of Test Case. Recommended order of elements in Test Cases: {recommended_order}

Documentation:

Settings or body in test case are out of order.

Sections should be defined in order set by sections_order parameter. Default order: documentation,tags,timeout,setup,template,keyword,teardown.

To change the default order use following option:

robocop check --configure test-case-section-out-of-order.sections_order=comma,separated,list,of,sections

where section should be case-insensitive name from the list:

• documentation

• tags

• timeout

• setup

• template

• keyword

• teardown

Order of not configured sections is ignored.

Incorrect code example:

*** Test Cases ***
Keyword After Teardown
    [Documentation]    This is test Documentation
    [Tags]    tag1    tag2
    [Teardown]    Log    abc
    Keyword1

Correct code:

*** Test Cases ***
Keyword After Teardown
    [Documentation]    This is test Documentation
    [Tags]    tag1    tag2
    Keyword1
    [Teardown]    Log    abc

Style guide:

• #test-cases-or-tasks

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
sections_order	documentation,tags,timeout,setup,template,keyword,teardown	str	order of sections in comma-separated list

---

ORD02: keyword-section-out-of-order

Added in v5.3.0 ⦁ Supported RF versions: All

Message:

'{section_name}' is in wrong place of Keyword. Recommended order of elements in Keyword: {recommended_order}

Documentation:

Settings or body in keyword are out of order.

Sections should be defined in order set by sections_order parameter. Default order: documentation,tags,arguments,timeout,setup,keyword,teardown.

To change the default order use following option:

robocop check --configure keyword-section-out-of-order.sections_order=comma,separated,list,of,sections

where section should be case-insensitive name from the list: documentation, tags, arguments, timeout, setup, keyword, teardown. Order of not configured sections is ignored.

Incorrect code example:

*** Keywords ***
Keyword After Teardown
    [Tags]    tag1    tag2
    [Teardown]    Log    abc
    Keyword1
    [Documentation]    This is keyword Documentation

Correct code example:

*** Keywords ***
Keyword After Teardown
    [Documentation]    This is keyword Documentation
    [Tags]    tag1    tag2
    Keyword1
    [Teardown]    Log    abc

Style guide:

• #keyword

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
sections_order	documentation,tags,arguments,timeout,setup,keyword,teardown	str	order of sections in comma-separated list

---

ORD03: section-out-of-order

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

'{section_name}' section header is defined in wrong order: {recommended_order}

Documentation:

Section does not follow recommended order.

It’s advised to use consistent section orders for readability.

Default order: comments,settings,variables,testcases,keywords.

To change the default order use following option:

robocop check --configure section-out-of-order.sections_order=comma,separated,list,of,sections

Order of not configured sections is ignored.

Incorrect code example:

*** Settings ***

*** Keywords ***

*** Test Cases ***

Correct code:

*** Settings ***

*** Test Cases ***

*** Keywords ***

Style guide:

• #sections

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
sections_order	settings,variables,testcases,keywords	str	order of sections in comma-separated list

Spacing

Spacing and whitespace related rules.

SPC01: trailing-whitespace

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Trailing whitespace at the end of line

Documentation:

Trailing whitespace at the end of line.

Invisible, unnecessary whitespace can be confusing.

Incorrect code example:

*** Keywords ***  \n
Validate Result\n
[Arguments]    ${variable}\n
    Should Be True    ${variable}    \n

Correct code:

*** Keywords ***\n
Validate Result\n
[Arguments]    ${variable}\n
    Should Be True    ${variable}\n

Style guide:

• #trailing-whitespaces

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

SPC02: missing-trailing-blank-line

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Missing trailing blank line at the end of file

Documentation:

Missing trailing blank line at the end of file.

Style guide:

• #spacing-after-sections

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

SPC03: empty-lines-between-sections

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Invalid number of empty lines between sections ({empty_lines}/{allowed_empty_lines})

Documentation:

Invalid number of empty lines between sections.

Ensure there is the same number of empty lines between sections for consistency and readability.

Incorrect code example:

*** Settings ***
Documentation    Only one empty line after this section.

*** Keywords ***
Keyword Definition
    No Operation

Correct code:

*** Settings ***
Documentation    Only one empty line after this section.


*** Keywords ***
Keyword Definition
    No Operation

Style guide:

• #spacing-after-sections

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
empty_lines	2	int	number of empty lines required between sections

---

SPC04: empty-lines-between-test-cases

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Invalid number of empty lines between test cases ({empty_lines}/{allowed_empty_lines})

Documentation:

Invalid number of empty lines between test cases.

Ensure there is the same number of empty lines between test cases for consistency and readability.

Incorrect code example:

*** Test Cases ***
First test case
    No Operation


Second test case
    No Operation

Correct code:

*** Test Cases ***
First test case
    No Operation

Second test case
    No Operation

Style guide:

• #spacing-after-test-cases-or-tasks

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
empty_lines	1	int	number of empty lines required between test cases

---

SPC05: empty-lines-between-keywords

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Invalid number of empty lines between keywords ({empty_lines}/{allowed_empty_lines})

Documentation:

Invalid number of empty lines between keywords.

Ensure there is the same number of empty lines between keywords for consistency and readability.

Incorrect code example:

*** Keywords ***
First Keyword
    No Operation


Second Keyword
    No Operation

Correct code:

*** Keywords ***
First Keyword
    No Operation

Second Keyword
    No Operation

Style guide:

• #spacing-after-keywords

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
empty_lines	1	int	number of empty lines required between keywords

---

SPC06: mixed-tabs-and-spaces

Added in v1.1.0 ⦁ Supported RF versions: All

Message:

Inconsistent use of tabs and spaces in file

Documentation:

Mixed tabs and spaces in file.

File contains both spaces and tabs. Use only one type of separators - preferably spaces.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

SPC08: bad-indent

Added in v3.0.0 ⦁ Supported RF versions: All

Message:

{bad_indent_msg}

Documentation:

Line is misaligned or indent is invalid.

This rule reports warning if the line is misaligned in the current block. The correct indentation is determined by the most common indentation in the current block. It is possible to switch for more strict mode using indent parameter (default -1).

Incorrect code example:

*** Keywords ***
Keyword
    Keyword Call
     Misaligned Keyword Call
    IF    $condition    RETURN
   Keyword Call

Correct code:

*** Keywords ***
Keyword
    Keyword Call
    Misaligned Keyword Call
    IF    $condition    RETURN
    Keyword Call

Style guide:

• #indentation

• #block-indentation

• #indentation-within-test-cases-tasks-and-keywords-section

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
indent	-1	int	Number of spaces per indentation level

---

SPC09: empty-line-after-section

Added in v1.2.0 ⦁ Supported RF versions: All

Message:

Too many empty lines after '{section_name}' section header ({empty_lines}/{allowed_empty_lines})

Documentation:

Too many empty lines after section header.

Empty lines after the section header are not allowed by default.

Incorrect code example:

*** Test Cases ***

Test case name

Correct code:

*** Test Cases ***
Test case name

Style guide:

• #spacing-after-the-section-header-line

Severity thresholds

This rule supports dynamic severity configurable using thresholds (Severity threshold). Parameter empty_lines will be used to determine issue severity depending on the thresholds.

When configuring thresholds remember to also set empty_lines - its value should be lower or equal to the lowest value in the threshold.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
empty_lines	0	int	number of empty lines allowed after section header

---

SPC10: too-many-trailing-blank-lines

Added in v1.4.0 ⦁ Supported RF versions: All

Message:

Too many blank lines at the end of file

Documentation:

Too many blank lines at the end of file.

There should be exactly one blank line at the end of the file.

Style guide:

• #spacing-after-sections

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

SPC11: misaligned-continuation

Added in v1.6.0 ⦁ Supported RF versions: All

Message:

Continuation marker is not aligned with starting row

Documentation:

Misaligned continuation marker.

Incorrect code example:

*** Settings ***
    Default Tags       default tag 1    default tag 2    default tag 3
...                default tag 4    default tag 5

*** Test Cases ***
Example
    Do X    first argument    second argument    third argument
  ...    fourth argument    fifth argument    sixth argument

Correct code:

*** Settings ***
Default Tags       default tag 1    default tag 2    default tag 3
...                default tag 4    default tag 5

*** Test Cases ***
Example
    Do X    first argument    second argument    third argument
    ...    fourth argument    fifth argument    sixth argument

Style guide:

• #variables-section-line-continuation

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

SPC12: consecutive-empty-lines

Added in v1.8.0 ⦁ Supported RF versions: All

Message:

Too many consecutive empty lines ({empty_lines}/{allowed_empty_lines})

Documentation:

Too many consecutive empty lines.

Incorrect code example:

*** Variables ***
${VAR}    value


${VAR2}    value


*** Keywords ***
Keyword
    Step 1


    Step 2

Correct code:

*** Variables ***
${VAR}    value
${VAR2}    value


*** Keywords ***
Keyword
    Step 1
    Step 2  # 1 empty line is also fine, but no more

Style guide:

• #settings-1

• #spacing-between-code-blocks-within-test-cases-or-tasks

• #spacing-between-code-blocks-within-keyword-calls

Severity thresholds

This rule supports dynamic severity configurable using thresholds (Severity threshold). Parameter empty_lines will be used to determine issue severity depending on the thresholds.

When configuring thresholds remember to also set empty_lines - its value should be lower or equal to the lowest value in the threshold.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
empty_lines	1	int	number of allowed consecutive empty lines

---

SPC13: empty-lines-in-statement

Added in v1.8.0 ⦁ Supported RF versions: All

Message:

Multi-line statement with empty lines

Documentation:

Multi line statement with empty lines.

Avoid using empty lines between continuation markers in multi line statement.

Incorrect code example:

*** Test Cases ***
Test case
    Keyword
    ...  1
    # empty line in-between multiline statement
    ...  2

    ...  3

Correct code:

*** Test Cases ***
Test case
    Keyword
    ...  1
    ...  2
    ...  3

Style guide:

• #spacing-of-line-continuations

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

SPC14: variable-not-left-aligned

Added in v1.8.0 ⦁ Supported RF versions: >=4.0

Message:

Variable in Variables section is not left aligned

Documentation:

Variable in *** Variables *** section should be left aligned.

Incorrect code example:

*** Variables ***
 ${VAR}  1
  ${VAR2}  2

Correct code:

*** Variables ***
${VAR}  1
${VAR2}  2

Style guide:

• #indentation-within-variables-section

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

SPC15: misaligned-continuation-row

Added in v1.11.0 ⦁ Supported RF versions: All

Message:

Continuation line is not aligned with the previous one

Documentation:

Continuation marker should be aligned with the previous one.

Incorrect code example:

*** Variable ***
${VAR}    This is a long string.
...       It has multiple sentences.
...         And this line is misaligned with previous one.

*** Test Cases ***
My Test
    My Keyword
    ...    arg1
    ...   arg2  # misaligned

Correct code:

*** Variable ***
${VAR}    This is a long string.
...       It has multiple sentences.
...       And this line is misaligned with previous one.

*** Test Cases ***
My Test
    My Keyword
    ...    arg1
    ...    arg2  # misaligned

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)
ignore_docs	True	bool	Ignore documentation
ignore_run_keywords	False	bool	Ignore run keywords

---

SPC16: suite-setting-not-left-aligned

Added in v2.4.0 ⦁ Supported RF versions: >=4.0

Message:

Setting in Settings section is not left aligned

Documentation:

Settings in *** Settings *** section should be left aligned.

Incorrect code example:

*** Settings ***
    Library  Collections
Resource  data.resource
    Variables  vars.robot

Correct code:

*** Settings ***
Library  Collections
Resource  data.resource
Variables  vars.robot

Style guide:

• #indentation-within-settings-section

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

SPC17: bad-block-indent

Added in v3.0.0 ⦁ Supported RF versions: All

Message:

Not enough indentation inside block

Documentation:

Not enough indentation.

Reports occurrences where indentation is less than two spaces than current block parent element (such as FOR/IF/WHILE/TRY header).

Incorrect code example:

*** Keywords ***
Some Keyword
    FOR  ${elem}  IN  ${list}
        Log  ${elem}  # this is fine
   Log  stuff    # this is bad indent
# bad comment
    END

Correct code:

*** Keywords ***
Some Keyword
    FOR  ${elem}  IN  ${list}
        Log  ${elem}  # this is fine
        Log  stuff    # this is bad indent
        # bad comment
    END

Style guide:

• #indentation

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

SPC18: first-argument-in-new-line

Added in v5.3.0 ⦁ Supported RF versions: All

Message:

First argument: '{argument_name}' is not placed on the same line as [Arguments] setting

Documentation:

First argument is not in the same level as [Arguments] setting.

Incorrect code example:

*** Keywords ***
Custom Keyword With Five Required Arguments
[Arguments]
...    ${name}
...    ${surname}

Correct code:

*** Keywords ***
Custom Keyword With Five Required Arguments
[Arguments]    ${name}
...    ${surname}

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

SPC19: not-enough-whitespace-after-setting

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Not enough whitespace after '{setting_name}' setting

Documentation:

Not enough whitespace after setting.

Provide at least two spaces after setting.

Incorrect code example:

*** Test Cases ***
Test
    [Documentation] doc
    Keyword

*** Keywords ***
Keyword
    [Documentation]  This is doc
    [Arguments] ${var}
    Should Be True  ${var}

Correct code:

*** Test Cases ***
Test
    [Documentation]  doc
    Keyword

*** Keywords ***
Keyword
    [Documentation]  This is doc
    [Arguments]    ${var}
    Should Be True  ${var}

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

SPC20: not-enough-whitespace-after-newline-marker

Added in v1.11.0 ⦁ Supported RF versions: All

Message:

Not enough whitespace after '...' marker

Documentation:

Not enough whitespace after newline marker.

Provide at least two spaces after newline marker.

Incorrect code example:

*** Variables ***
@{LIST}  1
... 2
...  3

Correct code:

*** Variables ***
@{LIST}  1
...  2
...  3

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

SPC21: not-enough-whitespace-after-variable

Added in v1.11.0 ⦁ Supported RF versions: >=4.0

Message:

Not enough whitespace after '{variable_name}' variable name

Documentation:

Not enough whitespace after variable.

Provide at least two spaces after variable name.

Incorrect code example:

*** Variables ***
${variable} 1
${other_var}  2

Correct code:

*** Variables ***
${variable}  1
${other_var}  2

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

---

SPC22: not-enough-whitespace-after-suite-setting

Added in v1.11.0 ⦁ Supported RF versions: All

Message:

Not enough whitespace after '{setting_name}' setting

Documentation:

Not enough whitespace after suite setting.

Provide at least two spaces after suite setting.

Incorrect code example:

*** Settings ***
Library Collections
Test Tags  tag
...  tag2
Suite Setup Keyword

Correct code:

*** Settings ***
Library    Collections
Test Tags  tag
...  tag2
Suite Setup    Keyword

Configurable parameters:

Name	Default value	Type	Description
severity	E	severity	Rule severity (E = Error, W = Warning, I = Info)

Tags

Rules for tags.

TAG01: tag-with-space

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Tag '{tag}' contains spaces

Documentation:

Tag with space.

When including or excluding tags, it may lead to unexpected behavior. It’s recommended to use short tag names without spaces.

Example of rule violation:

*** Test Cases ***
Test
    [Tags]  tag with space    ${tag with space}

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

TAG02: tag-with-or-and

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Tag '{tag}' with reserved word OR/AND

Documentation:

OR or AND keyword found in the tag.

OR and AND words are used to combine tags when selecting tests to be run in Robot Framework. Using following configuration:

robocop check --include tagANDtag2

Robot Framework will only execute tests that contain tag and tag2. That’s why it’s best to avoid AND and OR in tag names. See docs for more information.

Tag matching is case-insensitive. If your tag contains OR or AND you can use lowercase to match it. For example, if your tag is PORT, you can match it with port.

Configurable parameters:

Name	Default value	Type	Description
severity	I	severity	Rule severity (E = Error, W = Warning, I = Info)

---

TAG03: tag-with-reserved-word

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Tag '{tag}' prefixed with reserved word `robot:`

Documentation:

Tag is prefixed with reserved work robot:.

robot: prefix is used by Robot Framework special tags. More details here. Special tags currently in use:

• robot:exit

• robot:flatten

• robot:no-dry-run

• robot:continue-on-failure

• robot:recursive-continue-on-failure

• robot:skip

• robot:skip-on-failure

• robot:stop-on-failure

• robot:recursive-stop-on-failure

• robot:exclude

• robot:private

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

TAG05: could-be-test-tags

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

All tests in suite share these tags: '{tags}'

Documentation:

All tests share the same tags which can be moved to Test Tags setting.

Example:

*** Test Cases ***
Test
    [Tags]  featureX  smoke
    Step

Test 2
    [Tags]  featureX
    Step

In this example all tests share one common tag featureX. It can be declared just once using Test Tags or Task Tags. This rule was renamed from could-be-force-tags to could-be-test-tags in Robocop 2.6.0.

Will ignore robot:* tags.

Configurable parameters:

Name	Default value	Type	Description
severity	I	severity	Rule severity (E = Error, W = Warning, I = Info)

---

TAG06: tag-already-set-in-test-tags

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Tag '{tag}' is already set by {test_force_tags} in suite settings

Documentation:

Tag is already set in the Test Tags setting.

Avoid repeating the same tags in tests when the tag is already declared in Test Tags or Force Tags. Example of rule violation:

*** Settings ***
Test Tags  common_tag

*** Test Cases ***
Test
    [Tags]  sanity  common_tag
    Some Keyword

This rule was renamed from tag-already-set-in-force-tags to tag-already-set-in-test-tags in Robocop 2.6.0.

Configurable parameters:

Name	Default value	Type	Description
severity	I	severity	Rule severity (E = Error, W = Warning, I = Info)

---

TAG07: unnecessary-default-tags

Added in v1.0.0 ⦁ Supported RF versions: All

Message:

Tags defined in Default Tags are always overwritten

Documentation:

Default Tags setting is always overwritten and is unnecessary.

Example of rule violation:

*** Settings ***
Default Tags  tag1  tag2

*** Test Cases ***
Test
    [Tags]  tag3
    Step

Test 2
    [Tags]  tag4
    Step

Since Test and Test 2 have [Tags] section, Default Tags setting is never used.

Configurable parameters:

Name	Default value	Type	Description
severity	I	severity	Rule severity (E = Error, W = Warning, I = Info)

---

TAG08: empty-tags

Added in v2.0.0 ⦁ Supported RF versions: All

Message:

[Tags] setting without values{optional_warning}

Documentation:

[Tags] setting without any value.

If you want to use empty [Tags] (for example to overwrite Default Tags) then use NONE value to be explicit.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

TAG09: duplicated-tags

Added in v2.0.0 ⦁ Supported RF versions: All

Message:

Multiple tags with name '{name}' (first occurrence at line {line} column {column})

Documentation:

Duplicated tags found.

Tags are free text, but they are normalized so that they are converted to lowercase and all spaces are removed. Only first tag is used, other occurrences are ignored.

Example of duplicated tags:

*** Test Cases ***
Test
    [Tags]    Tag    TAG    tag    t a g

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

TAG10: could-be-keyword-tags

Added in v3.3.0 ⦁ Supported RF versions: >=6

Message:

All keywords in suite share these tags: '{tags}'

Documentation:

All keywords share the same tags which can be moved to Keyword Tags setting.

Example:

*** Keywords ***
Keyword
    [Tags]  featureX  smoke
    Step

Keyword
    [Tags]  featureX
    Step

In this example all keywords share one common tag featureX.It can be declared just once using Keyword Tags.

Will ignore robot:* tags.

Configurable parameters:

Name	Default value	Type	Description
severity	I	severity	Rule severity (E = Error, W = Warning, I = Info)

---

TAG11: tag-already-set-in-keyword-tags

Added in v3.3.0 ⦁ Supported RF versions: >=6

Message:

Tag '{tag}' is already set by {keyword_tags} in suite settings

Documentation:

Tag is already set in the Test Keyword setting.

Avoid repeating the same tags in keywords when the tag is already declared in Keyword Tags. Example of rule violation:

*** Settings ***
Keyword Tags  common_tag

*** Keywords ***
Keyword
    [Tags]  sanity  common_tag

Configurable parameters:

Name	Default value	Type	Description
severity	I	severity	Rule severity (E = Error, W = Warning, I = Info)

Variables

Rules for variables.

VAR01: empty-variable

Added in v1.10.0 ⦁ Supported RF versions: All

Message:

Empty variable value

Documentation:

Variable without value.

Variables with placeholder ${EMPTY} values are more explicit.

Incorrect code example:

*** Variables ***
${VAR_NO_VALUE}
${VAR_WITH_EMPTY}    ${EMPTY}
@{MULTILINE_FIRST_EMPTY}
...
...    value
${EMPTY_WITH_BACKSLASH}  \

Correct code:

*** Keywords ***
Create Variables
    VAR    @{var_no_value}
    VAR    ${var_with_empty}    ${EMPTY}

Incorrect code example::

*** Variables ***
${VAR_NO_VALUE}    ${EMPTY}
${VAR_WITH_EMPTY}    ${EMPTY}
@{MULTILINE_FIRST_EMPTY}
...    ${EMPTY}
...    value
${EMPTY_WITH_BACKSLASH}  \


*** Keywords ***
Create Variables
    VAR    @{var_no_value}    @{EMPTY}
    VAR    ${var_with_empty}    ${EMPTY}

You can configure empty-variable rule to run only in `*** Variables ***` section or on VAR statements using variable_source parameter.

Configurable parameters:

Name	Default value	Type	Description
severity	I	severity	Rule severity (E = Error, W = Warning, I = Info)
variable_source	section,var	comma separated list	Variable sources that will be checked

---

VAR02: unused-variable

Added in v3.2.0 ⦁ Supported RF versions: All

Message:

Variable '{name}' is assigned but not used

Documentation:

Unused variable.

Incorrect code example:

*** Keywords ***
Get Triangle Base Points
    [Arguments]       ${triangle}
    ${p1}    ${p2}    ${p3}    Get Triangle Points    ${triangle}
    Log      Triangle base points are: ${p1} and ${p2}.
    RETURN   ${p1}    ${p2}  # ${p3} is never used

Use ${_} variable name if you purposefully do not use variable:

*** Keywords ***
Process Value 10 Times
    [Arguments]    ${value}
    FOR    ${_}   IN RANGE    10
        Process Value    ${value}
    END

Note that some keywords may use your local variables even if you don’t pass them directly. For example BuiltIn Replace Variables or any custom keyword that retrieves variables from local scope. In such case Robocop will still raise unused-variable even if variable is used.

Configurable parameters:

Name	Default value	Type	Description
severity	I	severity	Rule severity (E = Error, W = Warning, I = Info)

---

VAR03: variable-overwritten-before-usage

Added in v3.2.0 ⦁ Supported RF versions: All

Message:

Local variable '{name}' is overwritten before usage

Documentation:

Local variable is overwritten before usage.

Local variable in Keyword, Test Case or Task is overwritten before it is used:

*** Keywords ***
Overwritten Variable
    ${value}    Keyword
    ${value}    Keyword

In case the value of the variable is not important, it is possible to use ${_} name:

*** Test Cases ***
Call keyword and ignore some return values
    ${_}    ${item}    Unpack List    @{LIST}
    FOR    ${_}    IN RANGE  10
        Log    Run this code 10 times.
    END

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

VAR04: no-global-variable

Added in v5.6.0 ⦁ Supported RF versions: All

Message:

Variable with global scope defined outside variables section

Documentation:

Global variable defined outside *** Variables *** section.

Setting or updating global variables in a test/keyword often leads to hard-to-understand code. In most cases, you’re better off using local variables.

Changes in global variables during a test are hard to track because you must remember what’s happening in multiple pieces of code at once. A line in a seemingly unrelated file can mess up your understanding of what the code should be doing.

Local variables don’t suffer from this issue because they are always created in the keyword/test you’re looking at.

In this example, the keyword changes the global variable. This will cause the test to fail. Looking at just the test, it’s unclear why the test fails. It only becomes clear if you also remember the seemingly unrelated keyword:

*** Variables ***
${hello}    Hello, world!

*** Test Cases ***
My Amazing Test
    Do A Thing
    Should Be Equal    ${hello}    Hello, world!

*** Keywords ***
Do A Thing
    Set Global Variable    ${hello}    Goodnight, moon!

Using the VAR-syntax:

*** Variables ***
${hello}    Hello, world!

*** Test Cases ***
My Amazing Test
    Do A Thing
    Should Be Equal    ${hello}    Hello, world!

*** Keywords ***
Do A Thing
    VAR    ${hello}    Goodnight, moon!    scope=GLOBAL

In some specific situations, global variables are a great tool. But most of the time, it makes code needlessly hard to understand.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

VAR05: no-suite-variable

Added in v5.6.0 ⦁ Supported RF versions: All

Message:

Variable defined with suite scope

Documentation:

Using suite variables in a test/keyword often leads to hard-to-understand code. In most cases, you’re better off using local variables.

Changes in suite variables during a test are hard to track because you must remember what’s happening in multiple pieces of code at once. A line in a seemingly unrelated file can mess up your understanding of what the code should be doing.

Local variables don’t suffer from this issue because they are always created in the keyword/test you’re looking at.

In this example, the keyword changes the suite variable. This will cause the test to fail. Looking at just the test, it’s unclear why the test fails. It only becomes clear if you also remember the seemingly unrelated keyword:

*** Test Cases ***
My Amazing Test
    Set Suite Variable    ${hello}    Hello, world!
    Do A Thing
    Should Be Equal    ${hello}    Hello, world!

*** Keywords ***
Do A Thing
    Set Suite Variable    ${hello}    Goodnight, moon!

Using the VAR-syntax:

*** Test Cases ***
My Amazing Test
    VAR    ${hello}    Hello, world!    scope=SUITE
    Do A Thing
    Should Be Equal    ${hello}    Hello, world!

*** Keywords ***
Do A Thing
    VAR    ${hello}    Goodnight, moon!    scope=SUITE

In some specific situations, suite variables are a great tool. But most of the time, it makes code needlessly hard to understand.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

VAR06: no-test-variable

Added in v5.6.0 ⦁ Supported RF versions: All

Message:

Variable defined with test/task scope

Documentation:

Using test/task variables in a test/keyword often leads to hard-to-understand code. In most cases, you’re better off using local variables.

Changes in test/task variables during a test are hard to track because you must remember what’s happening in multiple pieces of code at once. A line in a seemingly unrelated file can mess up your understanding of what the code should be doing.

Local variables don’t suffer from this issue because they are always created in the keyword/test you’re looking at.

In this example, the keyword changes the test/task variable. This will cause the test to fail. Looking at just the test, it’s unclear why the test fails. It only becomes clear if you also remember the seemingly unrelated keyword:

*** Test Cases ***
My Amazing Test
    Set Test Variable    ${hello}    Hello, world!
    Do A Thing
    Should Be Equal    ${hello}    Hello, world!

*** Keywords ***
Do A Thing
    Set Test Variable    ${hello}    Goodnight, moon!

Using the VAR-syntax:

*** Test Cases ***
My Amazing Test
    VAR    ${hello}    Hello, world!    scope=TEST
    Do A Thing
    Should Be Equal    ${hello}    Hello, world!

*** Keywords ***
Do A Thing
    VAR    ${hello}    Goodnight, moon!    scope=TEST

In some specific situations, test/task variables are a great tool. But most of the time, it makes code needlessly hard to understand.

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

VAR07: non-local-variables-should-be-uppercase

Added in v1.4.0 ⦁ Supported RF versions: All

Message:

Non local variable is not uppercase

Documentation:

Non-local variable is not uppercase.

Non-local variable is not uppercase to easily identify scope of the variable.

Incorrect code example:

*** Test Cases ***
Test case
    Set Task Variable    ${my_var}           1
    Set Suite Variable   ${My Var}           1
    Set Test Variable    ${myvar}            1
    Set Global Variable  ${my_var${NESTED}}  1

Correct code:

*** Test Cases ***
Test case
    Set Task Variable    ${MY_VAR}           1
    Set Suite Variable   ${MY VAR}           1
    Set Test Variable    ${MY_VAR}           1
    Set Global Variable  ${MY VAR${nested}}  1

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

VAR08: possible-variable-overwriting

Added in v1.10.0 ⦁ Supported RF versions: All

Message:

Variable '{variable_name}' may overwrite similar variable inside '{block_name}' {block_type}

Documentation:

Variable may overwrite similar variable inside code block.

Variable names are case-insensitive, and also spaces and underscores are ignored. Following assignments overwrite the same variable:

*** Keywords ***
Retrieve Usernames
    ${username}      Get Username       id=1
    ${User Name}     Get Username       id=2
    ${user_name}     Get Username       id=3

Use consistent variable naming guidelines to avoid unintended variable overwriting.

Configurable parameters:

Name	Default value	Type	Description
severity	I	severity	Rule severity (E = Error, W = Warning, I = Info)

---

VAR09: hyphen-in-variable-name

Added in v1.10.0 ⦁ Supported RF versions: All

Message:

Hyphen in variable name '{variable_name}'

Documentation:

Hyphen in the variable name.

Hyphens can be treated as minus sign by Robot Framework. If it is not intended, avoid using hyphen (-) character in variable name.

Incorrect code example:

*** Test Cases ***
Test case
    ${var2}  Set Variable  ${${var}-${var2}}

That’s why there is a possibility that hyphen in name is not recognized as part of the name but as a minus sign. Better to use underscore instead:

Correct code:

*** Test Cases ***
Test case
    ${var2}  Set Variable  ${${var}_${var2}}

Hyphens in *** Variables *** section or in [Arguments] are also reported for consistency reason.

Configurable parameters:

Name	Default value	Type	Description
severity	I	severity	Rule severity (E = Error, W = Warning, I = Info)

---

VAR10: inconsistent-variable-name

Added in v3.2.0 ⦁ Supported RF versions: All

Message:

Variable '{name}' has inconsistent naming. First used as '{first_use}'

Documentation:

Variable with inconsistent naming.

Variable names are case-insensitive and ignore underscores and spaces. It is possible to write the variable in multiple ways, and it will be a valid Robot Framework code. However, it makes it harder to maintain the code that does not follow the consistent naming.

Incorrect code example:

*** Keywords ***
Check If User Is Admin
    [Arguments]    ${username}
    ${role}    Get User Role     ${username}
    IF    '${ROLE}' == 'Admin'   # inconsistent name with ${role}
        Log    ${Username} is an admin  # inconsistent name with ${username}
    ELSE
        Log    ${user name} is not an admin  # inconsistent name
    END

Correct code:

*** Keywords ***
Check If User Is Admin
    [Arguments]    ${username}
    ${role}    Get User Role     ${username}
    IF    '${role}' == 'Admin'
        Log    ${username} is an admin
    ELSE
        Log    ${username} is not an admin
    END

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

VAR11: overwriting-reserved-variable

Added in v3.2.0 ⦁ Supported RF versions: All

Message:

{var_or_arg} '{variable_name}' overwrites reserved variable '{reserved_variable}'

Documentation:

Variable overwrites reserved variable.

Overwriting reserved variables may bring unexpected results. For example, overwriting variable with name ${LOG_LEVEL} can break Robot Framework logging. See the full list of reserved variables at Robot Framework User Guide

Configurable parameters:

Name	Default value	Type	Description
severity	W	severity	Rule severity (E = Error, W = Warning, I = Info)

---

VAR12: duplicated-assigned-var-name

Added in v1.12.0 ⦁ Supported RF versions: All

Message:

Assigned variable name '{variable_name}' is already used

Documentation:

Variable names in Robot Framework are case-insensitive and ignores spaces and underscores. Following variables are duplicates:

*** Test Cases ***
Test
    ${var}  ${VAR}  ${v_ar}  ${v ar}  Keyword

It is possible to use ${_} to note that variable name is not important and will not be used:

*** Keywords ***
Get Middle Element
    [Arguments]    ${list}
    ${_}    ${middle}    ${_}    Split List    ${list}
    RETURN    ${middle}

Configurable parameters:

Name	Default value	Type	Description
severity	I	severity	Rule severity (E = Error, W = Warning, I = Info)