Currently a test can describe the target architecture binary that it should primarily be run with, be setting a single tag value. The same approach is expected to be done with other QEMU aspects to be tested, for instance, the machine type and accelerator, so let's generalize the logic into a utility method. Signed-off-by: Cleber Rosa <crosa@redhat.com> Message-Id: <20190924194501.9303-3-crosa@redhat.com> Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Cleber Rosa <crosa@redhat.com> |
||
---|---|---|
.. | ||
avocado_qemu | ||
boot_linux_console.py | ||
cpu_queries.py | ||
empty_cpu_model.py | ||
linux_initrd.py | ||
linux_ssh_mips_malta.py | ||
machine_m68k_nextcube.py | ||
machine_sparc_leon3.py | ||
migration.py | ||
pc_cpu_hotplug_props.py | ||
ppc_prep_40p.py | ||
README.rst | ||
version.py | ||
virtio_version.py | ||
vnc.py | ||
x86_cpu_model_versions.py |
============================================ Acceptance tests using the Avocado Framework ============================================ This directory contains functional tests, also known as acceptance level tests. They're usually higher level, and may interact with external resources and with various guest operating systems. For more information, please refer to ``docs/devel/testing.rst``, section "Acceptance tests using the Avocado Framework".