Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1387432pxb; Thu, 21 Oct 2021 23:12:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz5HyKkjrGuU4mQbq7ExectqK6iMWxhW//3Vwc07ho0b3SSbNd+xV2oIn8zd+br/PNUwAm4 X-Received: by 2002:a17:906:a94b:: with SMTP id hh11mr13067314ejb.85.1634883172522; Thu, 21 Oct 2021 23:12:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634883172; cv=none; d=google.com; s=arc-20160816; b=nAPZSZTK8mntDx9LlPa+iB97jWsnHfANHsgMlLBFmESq2eBSKGlgp5VuNnWmjQzZdU 8ekggo4FwDkIa3tWo6GF+p9dRCg8VxF/DP2WARJbdgeTf9DSiDlsHjT3XbHuudwoSrdd 9cjIsHZENAOnBwX/XuQV9dg6UXFBqc7vKbPhXSgZ4QIJ9kJrEUh3hUlDXclcjtHmfXBP k4vAYuujo3fTdxPpGCcj4S359wCXd4FQkELy0x92v1402ByRoeXNgjyFuhrYplb9jI6j tG8bXaQdXS+Kk10Dqc761ZsIj4hZxwNkw3fN/Fu7ZxfydGbvb4/T36/hv5pFtpojQnZt TU5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=ri37NUrCIz+RJ7u4QEcy6nQ+rRdgNnFnx1wBKzaAWuA=; b=nPQvhp6fZzzp10QI4jiU5S6LPINWKgGB1Vz5YSzG5d3MQ7gOE7pg91Gp19Akvb9Yrz s6hcbkiodg8rMw4+wz3Om6Wt3xJiEVGh5fMRpflw8qwMv/95VfuBeYvNdy1H8cCcWwUn YiTMUuJo+Xezf55DUZiqzyt9Krs4xy/ocKat5UEmuwKlR32WQxQuHZoKpinFvsCbWXoe EjtPdv//aku639Q8O528YxcJfCppVm1y0+aYaNeLoVCQdITqwWWEY3wet3WSQ2+/80+K BA1tl7fQJIDT9FIr0+cqeiv1L0stJiX3FIdhnZ/FIX3cVwp7I5Op0WjkJwa1fh7nJMoI NUOg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=bFqJmuq0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b14si12869125edd.248.2021.10.21.23.12.20; Thu, 21 Oct 2021 23:12:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=bFqJmuq0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230086AbhJVGMw (ORCPT + 99 others); Fri, 22 Oct 2021 02:12:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54580 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229484AbhJVGMw (ORCPT ); Fri, 22 Oct 2021 02:12:52 -0400 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C0906C061766 for ; Thu, 21 Oct 2021 23:10:34 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id z14so2059343wrg.6 for ; Thu, 21 Oct 2021 23:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ri37NUrCIz+RJ7u4QEcy6nQ+rRdgNnFnx1wBKzaAWuA=; b=bFqJmuq0jQzmYQ7F6KHJD/td/GbSkeTqYnfmqlUzMMBZLE6Ybhx0EHdanecOqJUyNz evGZdKg8hKjc3k2JAzENDx8cVTLI834bc39bNVP+aQPWv7pdV19smsK16axTKD6CARqV yGH29I3m+Ys4MbTt6rTU+NfGQBGBURzJoILck/dr1Anauk5qv0H7pLNFI/5pzoH12eH8 8Z5ce+M9u2o42YUwQCI+QVuAdXjPBrPPKbaJXZcVITu1DkSAAh2dOv8MOyBDQfx+/7/i UkiNkmDgi5p2R4LJxSVmKOVXz01B9MPqqCLP87NeMGHmyrif5vNVGM++o6cQ7yX/dIE4 g7LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ri37NUrCIz+RJ7u4QEcy6nQ+rRdgNnFnx1wBKzaAWuA=; b=1kKEVhxCb+aqDJJ4tfbuixWFvkSyXoGwbOWGy89RW3KhGlRPuOhFH/rpLIU2+48Md3 EJ9qLxp4+2EOB+aVelb2dedUrQmn7v1a2ht0NTRfHOdOAmzvBCieyNFUTd/a13fCOQYc Sl7YkDFN+GmKBo9MQqFLL7ba3XME/K010ugLgGc2TPPi+XAzeNOQ9QB537jX7eUl5kfz N9qz7cx3RA+dYUSQahJUr9u3t1dNZ863e+ROclvREuxapoVnRwBk8WVxeAG+FKduRGG6 NazLet6rEa3HcsI/TcMBxnxiVppMsYrnG1NlPpXdNoQUdQEyJUBg0lR18pvz5nEHAth4 wAYQ== X-Gm-Message-State: AOAM531iy9QVH1/uEcjTnr82SnM+dsXIVDqqk3sTl7iovw7xOPmgP8DH ceGeyEyAHa0NBPKVE7gvW+nvlB7/qHPuvKTsoghp5A== X-Received: by 2002:a5d:4882:: with SMTP id g2mr12929352wrq.399.1634883033051; Thu, 21 Oct 2021 23:10:33 -0700 (PDT) MIME-Version: 1.0 References: <20211021062819.1313964-1-davidgow@google.com> In-Reply-To: From: David Gow Date: Fri, 22 Oct 2021 14:10:21 +0800 Message-ID: Subject: Re: [PATCH 1/2] kunit: tool: Do not error on tests without test plans To: Daniel Latypov Cc: Brendan Higgins , Rae Moar , Shuah Khan , KUnit Development , "open list:KERNEL SELFTEST FRAMEWORK" , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 22, 2021 at 9:29 AM Daniel Latypov wrote: > > On Wed, Oct 20, 2021 at 11:28 PM David Gow 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 > > --- > > 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 < 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 > >