From: "Alex Bennée" <alex.bennee@linaro.org>
To: Thomas Huth <thuth@redhat.com>
Cc: wrampazz@redhat.com, philmd@redhat.com, qemu-devel@nongnu.org,
Wainer dos Santos Moschetta <wainersm@redhat.com>,
crosa@redhat.com
Subject: Re: [PATCH] docs/devel: Explain how acceptance tests can be skipped
Date: Thu, 14 Jan 2021 10:30:41 +0000 [thread overview]
Message-ID: <87turjlrzz.fsf@linaro.org> (raw)
In-Reply-To: <d79dad7f-ba62-a79a-3a51-394c8314935f@redhat.com>
Thomas Huth <thuth@redhat.com> writes:
> On 13/01/2021 20.52, Wainer dos Santos Moschetta wrote:
>> Documented under the "Acceptance tests using the Avocado Framework"
>> section in testing.rst how environment variables are used to skip tests.
>>
>> Signed-off-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
>> ---
>> CI (success): https://gitlab.com/wainersm/qemu/-/pipelines/241249714
>>
>> docs/devel/testing.rst | 62 ++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 62 insertions(+)
>>
>> diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
>> index 0aa7a13bba..3cdb458565 100644
>> --- a/docs/devel/testing.rst
>> +++ b/docs/devel/testing.rst
>> @@ -871,6 +871,68 @@ qemu_bin
>>
>> The exact QEMU binary to be used on QEMUMachine.
>>
>> +Skipping tests
>> +--------------
>> +The Avocado framework provides Python decorators which allow for easily skip
>> +tests running under certain conditions. For example, on the lack of a binary
>> +on the test system or when the running environment is an CI system. For further
>
> s/is an CI/is a CI/
>
>> +information about those decorators, please refer to::
>> +
>> + https://avocado-framework.readthedocs.io/en/latest/guides/writer/chapters/writing.html#skipping-tests
>> +
>> +While the conditions for skipping tests are often specifics of each one, there
>> +are recurring scenarios identified by the QEMU developers and the use of
>> +environment variables became a kind of standard way to enable/disable tests.
>> +
>> +It follows a not comprehensive list of those variables.
>
> s/It follows a/Here is a/ ?
There now follows a non-comprehensive list of those variables:
?
I'm not sure if that is idiomatic international English or just British
English - it's usually a phrase that precedes our party political
broadcasts on TV ;-)
>
>> +AVOCADO_ALLOW_LARGE_STORAGE
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +Tests which are going to fetch or produce assets considered *large* are not
>> +going to run unless that `AVOCADO_ALLOW_LARGE_STORAGE=1` is exported on
>> +the environment.
>> +
>> +The definition of *large* is a bit arbitrary here, but it usually means an
>> +asset which occupies at least 1GB of size on disk when uncompressed.
>> +
>> +AVOCADO_ALLOW_UNTRUSTED_CODE
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +There are tests which will boot a kernel image or firmware that can be
>> +considered not safe to run on the developer's workstation, thus they are
>> +skipped by default. The definition of *not safe* is also arbitrary but
>> +usually it means a blob which either its source or build process aren't
>> +public available.
>> +
>> +You should export `AVOCADO_ALLOW_UNTRUSTED_CODE=1` on the environment in
>> +order to allow tests which make use of those assets to get running.
>
> maybe better: "... which make use of those kind of assets." ?
>
>> +AVOCADO_TIMEOUT_EXPECTED
>> +~~~~~~~~~~~~~~~~~~~~~~~~
>> +The Avocado framework has a timeout mechanism which interrupt tests to avoid the
>
> s/interrupt/interrupts/
>
>> +test suite of getting stuck. The timeout value can be set via test parameter or
>> +property defined in the test class, for further details::
>> +
>> + https://avocado-framework.readthedocs.io/en/latest/guides/writer/chapters/writing.html#setting-a-test-timeout
>> +
>> +Even though the timeout can be set by the test developer, there are some tests
>> +that may not have a well-defined limit of time to finish under certain
>> +conditions. For example, tests that take longer to execute when QEMU is
>> +compiled with debug flags. Therefore, the `AVOCADO_TIMEOUT_EXPECTED` variable
>> +has been used to determine whether those tests should run or not.
>> +
>> +GITLAB_CI
>> +~~~~~~~~~
>> +A number of tests are flagged to not run on the GitLab CI. Usually because
>> +they proved to the flaky or there are constraints on the CI environment which
>> +would make them fail. If you encounter a similar situation then use that
>> +variable as shown on the code snippet below to skip the test:
>> +
>> +.. code::
>> +
>> + @skipIf(os.getenv('GITLAB_CI'), 'Running on GitLab')
>> + def test(self):
>> + do_something()
>> +
>> Uninstalling Avocado
>> --------------------
>>
>
> Thomas
--
Alex Bennée
prev parent reply other threads:[~2021-01-14 10:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-13 19:52 [PATCH] docs/devel: Explain how acceptance tests can be skipped Wainer dos Santos Moschetta
2021-01-14 8:22 ` Thomas Huth
2021-01-14 10:30 ` Alex Bennée [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87turjlrzz.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=crosa@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
--cc=wainersm@redhat.com \
--cc=wrampazz@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.