- 23 May, 2022 3 commits
-
-
intrigeri authored
Without this, the "I can start the Unsafe Browser in a few supported languages" step always fails when our test suite tries using a Portuguese locale.
-
intrigeri authored
I see a number of weird failures where an image is not found on the screen, while I would expect it to be: calling opencv_match_template.py with the same arguments our test suite does in the context of those failures does find the image on the screen. So I suspect something down the call chain is slower than it used to be (taking the screenshot? OpenCV?), which could make the try_for timeout before the image has actually appeared. This debug logging will give us timing information that'll be useful to tell whether this is actually the case.
- 13 May, 2022 14 commits
-
-
intrigeri authored
In some scenarios we run: 1. "I set an administration password", which ends with validating the chosen password with "Return" in the Administration Password dialog. 2. "I log in to a new session", which expects the Administration Password dialog to have vanished already. This is racy so step (2) often fails to find TailsGreeterLoginButton.png on the screen. Let's ensure step (1) has finished its job before returning.
-
intrigeri authored
Recently I've seen numerous cases where the "Create new room" dialog is displayed pretty quickly, but it is initially empty, and only after a few seconds the "Accept Defaults" button appears. Without this change, when this happens we would fail because we assumed that button would be on screen as soon as the dialog appeared.
-
intrigeri authored
I've seen the test suite fails to find these images on screen a few times recently, while they seemed to be there, so perhaps they needs a refresh (and whether it succeeds or not depends on whether we give OpenCV enough time to find the picture with a lower sensitivity despite the differences).
-
intrigeri authored
We're checking the *guest*'s clock here, not the host.
-
intrigeri authored
Previously we would pretend the clock was expected to be set to the lower bound of the acceptable interval, which was incorrect.
-
intrigeri authored
I've seen this fail: Given I have started Tails from DVD without network and logged in When I bump the hardware clock's time with "-15 days" And I warm reboot the computer And the computer reboots Tails Then the hardware clock is still off by "-15 days" With that error: The host's hwclock should be approximately '2022-04-27 02:24:44 +0000' but is actually '2022-04-27 02:24:59 +0000'. <false> is not true. (Test::Unit::AssertionFailedError) ./features/step_definitions/time_syncing.rb:116:in `/^the hardware clock is still off by "([^"]+)"$/' features/time_syncing.feature:46:in `Then the hardware clock is still off by "-15 days"' Given expected_time_lower_bound == expected - max_time_drift, then expected_time_upper_bound == expected_time_lower_bound + max_time_drift == expected, which means we did not accept the clock to be in the future at all. Let's accept that it can be up to 1 second in the future, which happened in the test suite run I quoted above.
-
intrigeri authored
This will be useful for the next commit.
-
intrigeri authored
-
intrigeri authored
-
- 12 May, 2022 16 commits
- 11 May, 2022 7 commits