lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 22 Oct 2021 14:10:21 +0800
From:   David Gow <davidgow@...gle.com>
To:     Daniel Latypov <dlatypov@...gle.com>
Cc:     Brendan Higgins <brendanhiggins@...gle.com>,
        Rae Moar <rmr167@...il.com>,
        Shuah Khan <skhan@...uxfoundation.org>,
        KUnit Development <kunit-dev@...glegroups.com>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] kunit: tool: Do not error on tests without test plans

On Fri, Oct 22, 2021 at 9:29 AM Daniel Latypov <dlatypov@...gle.com> wrote:
>
> On Wed, Oct 20, 2021 at 11:28 PM David Gow <davidgow@...gle.com> wrote:
> >
> > The (K)TAP spec encourages test output to begin with a 'test plan': a
> > count of the number of tests being run of the form:
> > 1..n
> >
> > However, some test suites might not know the number of subtests in
> > advance (for example, KUnit's parameterised tests use a generator
> > function). In this case, it's not possible to print the test plan in
> > advance.
> >
> > kunit_tool already parses test output which doesn't contain a plan, but
> > reports an error. Since we want to use nested subtests with KUnit
> > paramterised tests, remove this error.
> >
> > Signed-off-by: David Gow <davidgow@...gle.com>
> > ---
> >  tools/testing/kunit/kunit_parser.py    | 5 ++---
> >  tools/testing/kunit/kunit_tool_test.py | 5 ++++-
> >  2 files changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/tools/testing/kunit/kunit_parser.py b/tools/testing/kunit/kunit_parser.py
> > index 3355196d0515..50ded55c168c 100644
> > --- a/tools/testing/kunit/kunit_parser.py
> > +++ b/tools/testing/kunit/kunit_parser.py
> > @@ -340,8 +340,8 @@ def parse_test_plan(lines: LineStream, test: Test) -> bool:
> >         """
> >         Parses test plan line and stores the expected number of subtests in
> >         test object. Reports an error if expected count is 0.
> > -       Returns False and reports missing test plan error if fails to parse
> > -       test plan.
> > +       Returns False and sets expected_count to None if there is no valid test
> > +       plan.
> >
> >         Accepted format:
> >         - '1..[number of subtests]'
> > @@ -356,7 +356,6 @@ def parse_test_plan(lines: LineStream, test: Test) -> bool:
> >         match = TEST_PLAN.match(lines.peek())
> >         if not match:
> >                 test.expected_count = None
> > -               test.add_error('missing plan line!')
>
> This works well, but there's an edge case.
>
> This patch means we no longer print an error when there are no test
> cases in a subtest.
> We relied on a check just a bit lower in this function.
>
> Consider
>
> $ ./tools/testing/kunit/kunit.py parse <<EOF
> TAP version 14
> 1..1
>   # Subtest: suite
>   1..1
>     # Subtest: case
>   ok 1 - case
> ok 1 - suite
> EOF
>
> This produces the following output (timestamps removed)
>
> ============================================================
> ==================== suite (1 subtest) =====================
> =========================== case ===========================
> ====================== [PASSED] case =======================
> ====================== [PASSED] suite ======================
> ============================================================
>
> Should we surface some sort of error here?

I thought about this a bit (and started prototyping it), and think the
answer is probably "no" (or, perhaps, "optionally"). Largely because I
think it'd be technically valid to have, e.g., a parameterised test
whose generator function can legitimately provide zero subtests. And
while that's probably worth warning about if it's the only test
running, if you're trying to run all tests, and one random subtest of
a test of a suite has no subtests, that seems like it'd be more
annoying to error on than anything else.

That being said, I'm not opposed to implementing it as an option, or
at least having the test status set to NO_ERROR. The implementation
I've experimented with basically moves the check to "parse_test", and
errors if the number of subtests is 0 after parsing, if parent_test is
true (or main, but my rough plan was to make main imply parent_test,
and adjust the various conditions to match). I haven't looked into
exactly how this is bubbled up yet, but I'd be okay with having an
error if there are no tests run at all.

I'll keep playing with this anyway: it's definitely a bit more of a
minefield than I'd originally thought. :-)

-- David

>
>
> >                 return False
> >         test.log.append(lines.pop())
> >         expected_count = int(match.group(1))
> > diff --git a/tools/testing/kunit/kunit_tool_test.py b/tools/testing/kunit/kunit_tool_test.py
> > index 9c4126731457..bc8793145713 100755
> > --- a/tools/testing/kunit/kunit_tool_test.py
> > +++ b/tools/testing/kunit/kunit_tool_test.py
> > @@ -191,7 +191,10 @@ class KUnitParserTest(unittest.TestCase):
> >                         result = kunit_parser.parse_run_tests(
> >                                 kunit_parser.extract_tap_lines(
> >                                 file.readlines()))
> > -               self.assertEqual(2, result.test.counts.errors)
> > +               # A missing test plan is not an error.
> > +               self.assertEqual(0, result.test.counts.errors)
> > +               # All tests should be accounted for.
> > +               self.assertEqual(10, result.test.counts.total())
> >                 self.assertEqual(
> >                         kunit_parser.TestStatus.SUCCESS,
> >                         result.status)
> > --
> > 2.33.0.1079.g6e70778dc9-goog
> >

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ