A manual run is good when something needs checking right now. The real benefit begins when the check runs by itself — every morning before the workday starts, for example. A schedule defines on which days and at which times the test runs. Below is how to set it up and what makes it fire.
What a schedule looks like
It is a weekly grid: days of the week and times. For example, “weekdays at 9:00 and 18:00”, or “Monday at 10:00”. A moment when a test was supposed to run is called a slot — a handy word when you are figuring out why a run did not arrive.
Times follow the project’s timezone, not the server’s. This matters when the server stands in another country: a 9 am schedule means 9 am where you are, not somewhere else. The timezone is set in the project’s settings.
The product sets a timer for the nearest firing time in advance, so a run arrives exactly in its minute, and not when the next check-by-round reaches the grid. Edit the schedule or switch it on or off, and the timer is re-armed at once.
An ordinary run lands in the run history. When a test declares snapshots, a scheduled run also appears on the “Verify” tab — the same place manual runs go.
Missed slots are not caught up
This is the most important thing about schedules, so it is best said outright: if at 9:00 the server or the executor computer was off, that run does not happen at all. The product will not catch up on the missed slot and will not fire the accumulated checks one after another once everything is back on. The next run arrives at its own slot.
The logic is simple: a check two days after the fact is almost useless, and an avalanche of catch-up runs would only occupy the executor. When a check is needed right now — run it manually.
The other case: the server is up, and there is no executor online. Then the test goes into the queue and waits. As soon as a browser appears, the run starts — waiting is appropriate here, because the slot has just passed.
When a test is deleted
The schedule disables itself: there is no point reminding about a test that no longer exists, and no point littering reports with errors. You do not need to clean schedules up after deleting tests.
The executor machine
The reliability of a schedule equals the reliability of the executor. A separate computer is no longer required: the built-in runner lives on the server itself, so the schedule fires even when all personal computers are off. Chrome with the addon in runner mode is kept where you want to see a run with your own eyes; for it, a dedicated browser profile or a whole computer is better, so runs never interfere with your everyday work.
Whether the executor is alive can be checked in the settings: for the built-in one — the “Built-in runner” row in Settings → UI testing, for the addon — the last-contact time on the addon’s settings page. Seconds and minutes mean everything is fine; hours mean the executor is asleep or the connection to the server is gone.
When runs do not arrive
- No executor online — the built-in runner is disabled, or the computer with Chrome is off, the browser is closed or the addon is disabled. Check the “Built-in runner” row in the UI-testing settings and the last-contact time in the addon’s settings.
- The slot was missed — look at the next run time: the product shows it next to the schedule in the project. A missed slot will not come back; you have to wait for the next one.
- A different timezone — the most common invisible mistake. Check the timezone in the project’s settings: because of it, 9:00 can mean a very different time of day.
- The schedule is off — that happens after the test was deleted, or when it was disabled by hand. Enable it and save.
Next: how run results become issues — in the Issues section.