What's New in RobotCode v2.7.0
RobotCode v2.7.0 is about running tests in the environment they actually need. The new wrapper option lets a command of your choosing bring up that environment — services, mocks, a graphical session — run the tests inside it, and tear it down again, from the command line and from your editor alike. Alongside it, the analysis cache is now trustworthy under rapid file changes, so stale errors no longer stick around in the editor or the CLI. And running a subset of tests from the VS Code Test Explorer works cleanly again on Robot Framework 6.1+.
Run Tests Through a Wrapper
Some test runs need more than the tests themselves: a database, a mock server, a docker compose stack, or a virtual display for UI tests. The new wrapper option tells RobotCode to run its actual command through a command of your choosing — the wrapper prepares the environment, runs the appended robotcode command in it, and cleans up afterwards.
Configure it per profile in robot.toml:
# A ready-made tool — here a virtual X server for headless UI tests
[profiles.headless]
wrapper = ["xvfb-run", "-a"]
# Your own script — bring the test environment up, then tear it down again
[profiles.integration]
wrapper = ["./with-test-services.sh"]Or set it ad hoc for a single run:
robotcode --wrapper "xvfb-run -a" run tests/
robotcode -p integration --no-wrapper run tests/ # ignore the profile's wrapperThe wrapper applies to every command that executes Robot Framework — run, robot, debug, repl, run-debug and repl-server — and never to commands that don't run tests, like the language server, discover, or libdoc. It can also be set through the ROBOTCODE_WRAPPER environment variable.
Editors pick it up automatically, because they run robotcode for you: a wrapper in your selected profile already wraps the tests you run or debug from the VS Code Test Explorer. If you want an editor-only override without touching robot.toml, set robotcode.debug.launchWrapper — it takes precedence over the profile's wrapper and has no effect on the command line.
If your run only needs environment variables, you still don't need a wrapper — keep using [env] in robot.toml. Reach for a wrapper when something has to run around the tests.
The wrapper works on Linux, macOS, and Windows — on POSIX systems RobotCode replaces itself with the wrapper command, on Windows it spawns it and forwards the exit code, and the contract for your script is the same everywhere. The new Running Tests Through a Wrapper reference explains the details and includes complete, copy-ready Bash and PowerShell wrapper scripts.
A Trustworthy Analysis Cache
Fast consecutive changes to several files could previously poison the analysis cache: the editor and the CLI then reported errors that did not exist — missing keywords, unresolvable variables — until the affected files were touched again.
In v2.7.0, cached analysis results are bound to exactly the file state they were computed from, and unsaved editor content is analyzed but never cached. Stale results can no longer stick, so what the editor and robotcode analyze code report reflects your files as they actually are — even while you are editing quickly across resource files, branches, or generated code.
Bug Fixes
- Running a subset of tests from the Test Explorer works again on Robot Framework 6.1+. Since 2.6.0, running a single test, a file, or any subset from the VS Code Test Explorer no longer passed Robot Framework's parse-include (
-I) and top-level suite name (-N) options, so the run parsed the whole workspace and surfaced parse errors from unrelated files. Both options are passed again. For scripts and agents consumingrobotcode discover -f json: Robot Framework's--parseincludesupport is now reported once as asupportsParseIncludekey on the result, replacing the previous per-itemneedsParseIncludekey. (#624)
There is also a small fix for JSON output: the compact JSON mode now actually emits compact separators instead of the pretty-printed spacing.
Thank You
Thanks to everyone who reported issues, contributed ideas, and tested pre-release builds. Your feedback drives every release.
For the full list of changes, see the Changelog.