A flaky test passes one run and fails the next, with nothing having changed. It is worse than a test that simply fails, because it teaches the team to ignore red. Most flakiness comes from a handful of causes, though, and Robot Framework gives you the tools to handle each one.
The usual causes, and how to fix them
- Timing. The test acts before the page is ready. With the Browser library you rarely need to think about this, because it waits for elements to be actionable before it acts. The fix is usually to remove manual
Sleepcalls and let the automatic waiting do its job. - Fragile selectors. A selector tied to position or a generated class name works today and breaks tomorrow. Prefer a stable selector, such as a custom test attribute, so the test keeps finding the right element.
- Shared state. When tests leave data or a session behind, the next test inherits it and fails at random. Isolate each test with setup and teardown, and give web tests a fresh browser context, so every test starts clean.
- Order dependence. A test that only passes when another ran first is flaky by design. Each test should set up what it needs and not rely on its neighbours.
- Uncontrolled data. Tests that depend on whatever happens to be in the system will wobble. Create or reset the data the test needs, so the result is the same every run.
Notice that none of these are complicated. They are the same reliability habits good testers reach for in any tool.
Reliability is designed in
The theme running through all of it is that a green suite is built, not patched. Stable selectors, proper isolation and trusting the framework's waiting are decisions you make while writing the test, not repairs you bolt on after it starts failing. Learning to build that in from the start is a large part of what separates a suite people trust from one they stop running. Our Robot Framework Certified Professional course teaches these habits as you learn the framework, and prepares you for the RFCP exam.
Frequently asked questions
Why is my Robot Framework test flaky? Usually timing, a fragile selector, or shared state left behind by another test. Each has a clear fix: rely on automatic waiting, use stable selectors, and isolate tests with setup and teardown.
Should I use Sleep to fix timing issues?
Almost never. A fixed Sleep is either too short, and still flaky, or too long, and slow. Let the Browser library wait for the element to be ready instead.
How do I stop tests affecting each other? Give each test its own setup and teardown, use a fresh browser context, and make sure no test depends on another having run first.
Related: stable selectors and setup and teardown.