Re: [kvm-unit-tests PATCH 2/4] doc: update unittests doc

Nicholas Piggin
2024-06-03T08:12:13Z

On Mon Jun 3, 2024 at 4:47 PM AEST, Andrew Jones wrote:
> On Sun, Jun 02, 2024 at 10:25:56PM GMT, Nicholas Piggin wrote:
> > Document the special groups, check path restrictions, and a small fix
> > for check option syntax.
> >
> > Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> > ---
> > docs/unittests.txt | 11 ++++++++---
> > 1 file changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/docs/unittests.txt b/docs/unittests.txt
> > index 6ff9872cf..509c529d7 100644
> > --- a/docs/unittests.txt
> > +++ b/docs/unittests.txt
> > @@ -69,8 +69,11 @@ groups
> > groups = <group_name1> <group_name2> ...
> >
> > Used to group the test cases for the `run_tests.sh -g ...` run group
> > -option. Adding a test to the nodefault group will cause it to not be
> > -run by default.
> > +option. The group name is arbitrary, except for these special groups:
> > +- Tests in the "nodefault" group are not run by default (with no -g option).
> > +- Tests in the "migration" group are run with the migration harness and
> > + expects the test to make migrate_*() calls.
>
> expect make migrate_*() calls.

Not sure if I follow you, but the grammar does sound a bit off now that
I read it back. Is this better?

"... are run with the migration harness and are expected to make
migrate_*() calls."

or

"... are run with the migration harness, which expects them to make
migrate_*() calls."

>
> > +- Tests in the "panic" group expect QEMU to enter the GUEST_PANICKED state.
> >
> > accel
> > -----
> > @@ -89,8 +92,10 @@ Optional timeout in seconds, after which the test will be killed and fail.
> >
> > check
> > -----
> > -check = <path>=<<value>
> > +check = <path>=<value>
> >
> > Check a file for a particular value before running a test. The check line
> > can contain multiple files to check separated by a space, but each check
> > parameter needs to be of the form <path>=<value>
> > +
> > +The path and value can not contain space, =, or shell wildcard characters.
>
> cannot

Huh, seems that is the more usual and formal form. I dind't know that.

Thanks,
Nick

>
> Otherwise,
>
> Reviewed-by: Andrew Jones <andrew.jones@linux.dev>
>
> Thanks,
> drew