QA » openQA Project

Motivation¶

We have multiple places in os-autoinst where we consider a "no_wait" scenario but use different sleeping times, e.g. 0.01s in https://github.com/os-autoinst/os-autoinst/pull/2109/files vs. 0.1s in https://github.com/os-autoinst/os-autoinst/pull/2164/files#diff-ee84fe6541d1e2e971e9e0d4bf0187272df8fa4ac878d033b1c8c600325e9f6dR185 . We should better avoid magic numbers with inconsistent usage for the same

Acceptance criteria¶

• AC1: In all cases of check_screen/assert_screen/wait_screen_change/wait_still_screen only a fraction of a second is spent when the expected screen content is already showing up (either in general or only if "no_wait" is used)
• AC2: We only use one common definition of a sleep interval (or timeout)

Suggestions¶

• Review the history when "no_wait" was introduced. "no_wait" was first introduced in
  commit e2b9c835, Author: Oliver Kurz okurz@suse.de, Date: Thu Jan 26 14:59:26 2017 +0100 "Add optional 'no_wait' parameter for check/assert_screen". The "no_wait" in "wait_still_screen" with 0.01s was introduced in f2a31c64

• Review occurences from $ git grep '\(sleep\|interval\).*\.0\?1' related to sleeping between test API checks

backend/baseclass.pm:        # note: Still keeping the interval at 0.1 s to avoid wasting too much CPU (corresponding to what check_screen/assert_screen
backend/baseclass.pm:        my @additional_intervals = $wait_screen_change && $wait_screen_change->{no_wait} ? (0.1) : ();
…
testapi.pm:        sleep($args{no_wait} ? 0.01 : 0.5);

there might be an additional 0.1s somewhere in isotovideo that mkittler mentioned. At best we can define the number with 0.01 consistently in a single place and use from there following up with what https://github.com/os-autoinst/os-autoinst/pull/2109/files#diff-3420c7e01f73caee7d97053af39990e3297daf42d06e0fc8848f78af1a5e009eR565 tried to do already.

• It might be the best solution to get rid of sleep calls completely if that is not required. Please check the impact on CPU usage when removing the sleep call
• Keep in mind that in one case we have an actual sleep call, in the other case it's an interval/timeout for something slightly different