Re: [PATCH v2 19/22] tests/qtest/migration: Add migration-test-smoke

[Peter Xu <peterx@redhat.com>]

On Wed, Nov 13, 2024 at 04:46:27PM -0300, Fabiano Rosas wrote:
> diff --git a/tests/qtest/migration-test-smoke.c b/tests/qtest/migration-test-smoke.c
> new file mode 100644
> index 0000000000..ff2d72881f
> --- /dev/null
> +++ b/tests/qtest/migration-test-smoke.c
> @@ -0,0 +1,39 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +
> +#include "qemu/osdep.h"
> +#include "libqtest.h"
> +#include "migration/test-framework.h"
> +#include "qemu/module.h"
> +
> +int main(int argc, char **argv)
> +{
> +    MigrationTestEnv *env;
> +    int ret;
> +
> +    g_test_init(&argc, &argv, NULL);
> +    env = migration_get_env();
> +    module_call_init(MODULE_INIT_QOM);
> +
> +    if (env->has_kvm) {
> +        g_test_message(
> +            "Smoke tests already run as part of the full suite on KVM hosts");
> +        goto out;
> +    }

So the "smoke" here is almost "tcg".. and if i want to run a smoke test on
a kvm-enabled host, it's noop.. which isn't easy to understand why.

If to rethink our goal, we have two requirements:

  (1) We want to categorize migration tests, so some are quick, some are
      slow, some might be flacky.  Maybe more, but it's about putting one
      test into only one bucket, and there're >1 buckets.

  (2) We want to run only a small portion of tests on tcg, more tests on
      kvm.

Ideally, we don't need two separate main test files, do we?

I mean, we can do (1) with the existing migration-test.c, with the help of
either gtest's "-m" or something we invent.  The only unfortunate part is
qtest only have quick/slow, afaiu the "thorough" mode is the same as
"slow".. while we don't yet have real "perf" tests.  It means we only have
two buckets if we want to reuse gtest's "-m".

Maybe it's enough?  If not, we can implement >2 categories in whatever
form, either custom argv/argc cmdline, or env variable.

Then, if we always categorize one test (let me try to not reuse glib's
terms to be clear) into any of: FAST|NORMAL|SLOW|..., then we have a single
migration-test that have different level of tests.  We can invoke
"migration-test --mode FAST" if kvm is not supported, and invoke the same
"migration-test --mode SLOW" if kvm is supported.

Would this be nicer?  At least we can still run a pretty fast smoke / FAST
test even on kvm. Basically, untangle accel v.s. "test category".

-- 
Peter Xu