Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp3885751pxb; Tue, 10 Nov 2020 02:36:14 -0800 (PST) X-Google-Smtp-Source: ABdhPJz/NrrS/ulz/hllKXjMMOiHcHP2S/xt52ExckkbUhReujiipNEyl6NFqoV2YBrQQ3+OMpGy X-Received: by 2002:aa7:dc09:: with SMTP id b9mr20574592edu.285.1605004574599; Tue, 10 Nov 2020 02:36:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605004574; cv=none; d=google.com; s=arc-20160816; b=uChfBIO7tLESFVtpaguE1/1Eb0J0/MVhDGVpmS8APUolHpZp7PWWHRV2E2S0ywg4fx zkTQHztexPOVdD0T0NofjmtrHoBP5A2q7VlWfWytbzMmt3taOkOaBC9aHGTgJKouVE/q bB5BOLK6VjQFRYJbS+JQ1agDxnH8alG0A8M/5EZbY74tXqI4/oeSg8y6FNYOAzaYVMG9 DfvtfneIgQ/ZJ3E53lyVXJZ1Qs4U4dSTcnxqVpseJCOm/s8FIR88GWVxnA7qkfJ6E4Wj tuK0qznncHQbtBA4Nm9qgwal0akEIwaN8iqSo5peuf0stnl1b1xsCI/jyqVQVoDZA3bG d2qA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=O9J78ygcMCgUaBelKJGuBDpmTHHQsSZqL7xxo9X1FXA=; b=SCHVchw33vJXWYH4jNs0mwxIwiC1XOFn4pPW7aB2O3kQImqR8XHpn+QynThwS6Lvlj AAZ79mapwKDgdifz9/P3nBCSFIl9RLWyCfJA9ampYPbnLrl3pltKxgjYCKd4lHm/+zYB ZusM1fPMsveq6me33ZdEghWeW5cmOj17IGdbNSbiDxY8vJG+s0kxQGA8SNwE551+8pa9 H1ZlWFH/q0xtgLR6iLQb+ueC+taYPBPr3IQcfHFE9vn5hKsezb6Z4m3SxqA6BMobXezl egfZCc3B2FCwOyXGrOxoNvG803UAjgwW/AsUe8ifsaI5gfC9FJUknbrZhRVBQTsJk0A6 i6NA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=iihJcLKg; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-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 t17si9279632edq.418.2020.11.10.02.35.42; Tue, 10 Nov 2020 02:36:14 -0800 (PST) Received-SPF: pass (google.com: domain of linux-ext4-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=20161025 header.b=iihJcLKg; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-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 S1726861AbgKJKfY (ORCPT + 99 others); Tue, 10 Nov 2020 05:35:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52334 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726280AbgKJKfY (ORCPT ); Tue, 10 Nov 2020 05:35:24 -0500 Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ABEE7C0613CF for ; Tue, 10 Nov 2020 02:35:23 -0800 (PST) Received: by mail-ot1-x343.google.com with SMTP id y22so12011890oti.10 for ; Tue, 10 Nov 2020 02:35:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=O9J78ygcMCgUaBelKJGuBDpmTHHQsSZqL7xxo9X1FXA=; b=iihJcLKgP4TSrgi/XOpJJLxcsC62DsZSrPSTjA7lSmML5YPgIbfpXonIcaUFoZ4xND ol7Q40wpQdgn6+48hn4iIVJ6RPMWatx/ll/y5aX3iBAd7l/30optiS9wz43TMfCYv+h2 3LULW2nv89gzaqh0QYHdlgFn2P0+LzgIU90KRsO6wMHpQ0w8DsUOkkgMf0fXnRBMJxed HtTMfxmVjzq/58yo17tXXg3HgGhrb84M40048Zb30zqZibfvPSs5A6k35uGVuJ4lFW8e 8EoBkoS3jGroVu5o/+71qHhYl/uiJ51xqICPvfWaZ+TSea4oO2tjl6O2lwl0D7vgzrKB BI5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=O9J78ygcMCgUaBelKJGuBDpmTHHQsSZqL7xxo9X1FXA=; b=q5Qym9iF7aTmqJWZh1kT7QhGTQuj/E8hPJKAnANiJQrE18ICuvU+CrPm0QuAF8XxEb J1O5dLsdnhoSupeUtytWrhVAeS76WcfC8QtslS+t5FmzNTx7fxuduHWujPgmoOUsBVft 6HGfh9nrQjMVVCGXK5/OEyvHR6xTRH7CAt96AcSD+1PBDwDfEQPbJSvxNh58ldkiDM0C bw1Q+PZssvBXdBkNGYKwJqYj3TfU5rYoJKn5Go1CEYReCpWLcyKTRBENaz/UL5a94jCE tff84DwVUiTBLg86UKOo9M93vRO4x+Bldc73r5E3/3NiwiIGogIQHC7XVuYJk+4BypG6 G1uQ== X-Gm-Message-State: AOAM530Dngqc44Czkw2II0lxt5Qpk4zHDglLSYwo52Ur+P/IcU18fslS 7M9bZ59tUiirW8OH4YyPuZ7WAxSa8iAgcznqOMrjSQ== X-Received: by 2002:a9d:f44:: with SMTP id 62mr14385069ott.17.1605004522694; Tue, 10 Nov 2020 02:35:22 -0800 (PST) MIME-Version: 1.0 References: <20201106192154.51514-1-98.arpi@gmail.com> <47a05c5a-485d-026b-c1c3-476ed1a97856@gmail.com> In-Reply-To: From: Marco Elver Date: Tue, 10 Nov 2020 11:35:11 +0100 Message-ID: Subject: Re: [PATCH v6 1/2] kunit: Support for Parameterized Testing To: David Gow Cc: Arpitha Raghunandan <98.arpi@gmail.com>, Brendan Higgins , Shuah Khan , Iurii Zaikin , "Theodore Ts'o" , Andreas Dilger , "open list:KERNEL SELFTEST FRAMEWORK" , KUnit Development , Linux Kernel Mailing List , linux-kernel-mentees@lists.linuxfoundation.org, linux-ext4@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue, 10 Nov 2020 at 08:21, David Gow wrote: [...] > > > > > > The previous attempt [1] at something similar failed because it seems > > > we'd need to teach kunit-tool new tricks [2], too. > > > [1] https://lkml.kernel.org/r/20201105195503.GA2399621@elver.google.c= om > > > [2] https://lkml.kernel.org/r/20201106123433.GA3563235@elver.google.c= om > > > > > > So if we go with a different format, we might need a patch before thi= s > > > one to make kunit-tool compatible with that type of diagnostic. > > > > > > Currently I think we have the following proposals for a format: > > > > > > 1. The current "# [test_case->name]: param-[index] [ok|not ok]" -- > > > this works well, because no changes to kunit-tool are required, and i= t > > > also picks up the diagnostic context for the case and displays that o= n > > > test failure. > > > > > > 2. Your proposed "# [ok|not ok] - [test_case->name]:param-[index]". > > > As-is, this needs a patch for kunit-tool as well. I just checked, and > > > if we change it to "# [ok|not ok] - [test_case->name]: param-[index]" > > > (note the space after ':') it works without changing kunit-tool. ;-) > > > > > > 3. Something like "# [ok|not ok] param-[index] - [test_case->name]", > > > which I had played with earlier but kunit-tool is definitely not yet > > > happy with. > > > > > > So my current preference is (2) with the extra space (no change to > > > kunit-tool required). WDYT? > > > > > Hmm=E2=80=A6 that failure in kunit_tool is definitely a bug: we shouldn't= care > what comes after the comment character except if it's an explicit > subtest declaration or a crash. I'll try to put a patch together to > fix it, but I'd rather not delay this just for that. > > In any thought about this a bit more, It turns out that the proposed > KTAP spec[1] discourages the use of ':', except as part of a subtest > declaration, or perhaps an as-yet-unspecified fully-qualified test > name. The latter is what I was going for, but if it's actively > breaking kunit_tool, we might want to hold off on it. > > If we were to try to treat these as subtests in accordance with that > spec, the way we'd want to use one of these options: > A) "[ok|not ok] [index] - param-[index]" -- This doesn't mention the > test case name, but otherwise treats things exactly the same way we > treat existing subtests. > > B) "[ok|not ok] [index] - [test_case->name]" -- This doesn't name the > "subtest", just gives repeated results with the same name. > > C) "[ok|not ok] [index] - [test_case->name][separator]param-[index]" > -- This is equivalent to my suggestion with a separator of ":", or 2 > above with a separator of ": ". The in-progress spec doesn't yet > specify how these fully-qualified names would work, other than that > they'd use a colon somewhere, and if we comment it out, ": " is > required. > > > > > Which format do we finally go with? > > > > I'm actually going to make another wild suggestion for this, which is > a combination of (1) and (A): > "# [test_case->name]: [ok|not ok] [index] - param-[index]" > > This gives us a KTAP-compliant result line, except prepended with "# > [test_case->name]: ", which makes it formally a diagnostic line, > rather than an actual subtest. Putting the test name at the start > matches what kunit_tool is expecting at the moment. If we then want to > turn it into a proper subtest, we can just get rid of that prefix (and > add the appropriate counts elsewhere). > > Does that sound good? Sounds reasonable to me! The repetition of [index] seems unnecessary for now, but I think if we at some point have a way to get a string representation of a param, we can substitute param-[index] with a string that represents the param. Note that once we want to make it a real subtest, we'd need to run the generator twice, once to get the number of params and then to run the tests. If we require that param generators are deterministic in the number of params generated, this is not a problem. Thanks, -- Marco