Linter¶
Lint your Robot Framework code by running:
It will recursively discover all *.robot and *.resource files in the current directory.
You can also use a specific path or paths:
Robocop will also find and skip paths from .gitignore files. It is possible to configure how Robocop discovers
files using various options (see file discovery).
An example of the output the tool can produce:
resources\operations.resource:15:5 VAR02 Variable '${var}' is assigned but not used
|
13 |
14 | Connect To Database
15 | ${conn} Setup Connection
| ^^^^^^ VAR02
|
tests\payments.robot:38:1 DEPR02 'Force Tags' is deprecated since Robot Framework version 6.0, use 'Test Tags' instead
|
36 | Metadata Version ${VERSION}
37 | Suite Setup Setup Payments
38 | Force Tags smoke payments
| ^^^^^^^^^^ DEPR02
|
It is also possible to produce simple or grouped output (see print_issues).
Rule selection¶
Robocop can be configured to run only selected rules. You can see what rules are currently enabled by running:
The following options can be used to select rules:
--select(see configuration reference) to only run selected rules--ignore(see configuration reference) to ignore and disabled rules--threshold(see configuration reference) to filter rules below a severity threshold--custom-rules(see configuration reference) to load custom rules
It is also possible to disable rules not available in the selected Robot Framework version using target version.
Rules can be also disabled in the code using disablers directives.
It is also possible to disable rules for specific file paths using the per_file_ignores option.
Auto-fixing Issues¶
Robocop can automatically fix many linting issues. Use the --fix flag to apply corrections:
By default, only safe fixes are applied. To also apply potentially unsafe fixes, use:
For more information about auto-fixing, see Auto-fixing.
## Reports
Robocop can generate reports in various formats, both as printed output and formatted files. By default, it uses
``print_issues`` default report to output found issues. You can configure it or enable more reports using
[the reports](../linter/reports/reports.md) option.
## Rule configuration
Rules and reports that support configuration can be configured using [``--configure``](../configuration/configuration_reference.md#configure)
option.
## Project checks
Project level rules are the rules that cannot be checked by looking at a single file. For example, to know that a
keyword is not used, Robocop has to know every keyword call in the project. All of them are disabled by default and
need to be selected:
```bash
robocop check --select unused-keyword --select invalid-argument-count
They are run by the check command together with the regular, file level rules. Selecting a project rule is the
only thing required - whenever at least one of them is enabled, Robocop additionally builds the project context by
parsing every source file, resolving Resource imports and indexing keyword definitions, keyword calls and
variables.
The project context is always built from the project root, even if only selected paths are linted. Thanks to that,
robocop check tests/login.robot still knows about keywords used in the rest of the project.
Project analysis takes noticeably more time than the regular linting. Use --no-project to skip it without
changing the configuration file, for example in a fast pre-commit run:
Project level rules execute code
To find out what keywords libraries provide, Robocop imports them. Python variable files provided with the
--variablefile option are imported as well. Both execute the code of the imported file. Libraries are
imported directly in the Robocop process, and failures are ignored, so a broken library never breaks the
analysis. Library analysis can be disabled with --no-analyze-libraries and single libraries can be skipped
with --ignored-library. Use --library-workers to import libraries in separate processes with a timeout.
Keywords of the successfully imported libraries are stored in the cache, so the next run does not have to import them again.
Currently available project level rules are:
unresolved-resource-import- imported resource file does not exist,unresolved-library-import- imported library cannot be imported,unused-keyword- user keyword is never called in the project,invalid-argument-count- keyword is called with a number of arguments its[Arguments]do not accept,missing-argument-name- keyword is called with a positional argument instead of a named one,unused-resource-import- nothing from the imported resource file is used,unused-library-import- no keyword from the imported library is used,ambiguous-keyword-name- keyword name matches keywords from more than one source,missing-keyword-prefix- keyword is called without the name of the resource file or library it comes from,keyword-not-found- called keyword is not defined anywhere (requires--analyze-libraries),circular-import- resource file imports, directly or indirectly, the file it is imported in,duplicated-variable-in-project- the same variable is defined in multiple files visible together.
Project rules are marked with the [project] tag in the rules list and can be listed with:
All of them can be enabled at once with the special PROJECT value, which can be used with --select,
--extend-select and --ignore:
robocop check --select PROJECT # run only the project level rules
robocop check --extend-select PROJECT # run the default rules and all project level rules
robocop check --select ALL --extend-select PROJECT # run every rule, including the project level ones
--select ALL does not enable the project rules. Since they are slower and require the whole project to be
parsed, they have to be selected explicitly - either by name, or with the PROJECT value.
Import paths often contain variables. Provide them with the --variable or --variablefile option so that the
imports can be resolved:
If the project relies on the Robot Framework --pythonpath option to find its resources or libraries, pass the
same locations to Robocop:
See variables, variable-files and python-path for more details.
Libraries are imported to check the keywords they provide. Every library is imported only once, by default synchronously in the Robocop process:
With --library-workers libraries are imported in parallel, each in a separate process which is stopped if it
takes longer than --load-library-timeout seconds (10 by default):
See analyze-libraries, library-workers, load-library-timeout and ignored-libraries for more details.
Project checks can be added as custom rules. See custom rules for more details.
Language support¶
Robot Framework 6.0 added support for Robot settings and headers translation.
Robocop will automatically detect the language of the source code if it contains a language header:
If the file does not contain a language header, --language option can be used to specify the language:
Robocop will not recognise translated
names unless it is properly configured. You can supply language code or name in the configuration using
--language option (see configuration reference).