Date:   Fri, 19 Jun 2020 13:17:32 -0500
From:   Frank Rowand <frowand.list@...il.com>
To:     Brendan Higgins <brendanhiggins@...gle.com>,
        "Bird, Tim" <Tim.Bird@...y.com>
Cc:     David Gow <davidgow@...gle.com>,
        "shuah@...nel.org" <shuah@...nel.org>,
        "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>
Subject: Re: RFC - kernel selftest result documentation (KTAP)

On 2020-06-16 15:03, Brendan Higgins wrote:
> On Mon, Jun 15, 2020 at 10:34 AM Bird, Tim <Tim.Bird@...y.com> wrote:
>>
>>> -----Original Message-----
>>> From: David Gow <davidgow@...gle.com>
>>>
>>> On Thu, Jun 11, 2020 at 2:11 AM Bird, Tim <Tim.Bird@...y.com> wrote:
> [...]
>>> KUnit is currently outputting "TAP version 14", as we were hoping some
>>> of our changes would get into the TAP14 spec. (Any comments, Brendan?)
>>> Maybe this should end up saying "KTAP version 1" or something?
>>
>> I don't know if this will break any existing results parsers or not.
>> I hesitate to use "TAP version 14", as TAP appears to be a dormant
>> initiative at the moment, and there's no guarantee that the kernel's
>> changes will get adopted into an official spec.
> 
> We were using "TAP version 14" since the "extensions" we are using
> were all proposed among the TAP people to go into the next version of
> TAP. Based on discussions among them they seem to like the subtest
> stuff:
> 
> https://github.com/TestAnything/testanything.github.io/pull/36
> 
> Anyway, I can still appreciate that they might change their minds.
> 
>> If we are a strict super-set of TAP, then I suppose we could just
>> start using TAP version 14, and unilaterally declare that our changes
>> make a new spec.  But since we don't control the web site this feels
>> like a hostile takeover.
> 
> I just thought it was okay because it was already in their proposed
> TAP14 spec, but yeah, if we just decide amongst ourselves to use it,
> we should probably do something else.
> 
>> I'm most comfortable with calling our thing KTAP, and just
>> referencing TAP as inspiration.  I don't have a strong opinion on
> 
> I am cool with that.

I like a KTAP specification, based on the proposed TAP 14, but with a
good edit, and with the extensions and changes that are coming out
of this conversation.

It would be great if we could just have a finished TAP 14, but my
understanding is that efforts to move that forward are not making
any progress.  And if we fork to make KTAP, maybe that will be
the incentive for TAP to move forward, and maybe KTAP could be
merged back into TAP.

-Frank

> 
>> KTAP vs TAP, but I do feel strongly that kselftest and kunit should use the
>> same version line (if we can get them to use the same conventions).
> 
> Yeah, I agree: it would be better if there was just one version of
> (K)TAP in the kernel.
> 
>>>> Test plan line
>>>> --------------
>>>> The test plan indicates the number of individual test cases intended to
>>>> be executed by the test. It always starts with "1.." and is followed
>>>> by the number of tests cases.  In the example above, 1..1", indicates
>>>> that this test reports only 1 test case.
>>>>
>>>> The test plan line can be placed in two locations:
>>>>  * the second line of test output, when the number of test cases is known
>>>>    in advance
>>>>  * as the last line of test output, when the number of test cases is not
>>>>    known in advance.
>>>>
>>>> Most often, the number of test cases is known in advance, and the test plan
>>>> line appears as the second line of test output, immediately following
>>>> the output version line.  The number of test cases might not be known
>>>> in advance if the number of tests is calculated from runtime data.
>>>> In this case, the test plan line is emitted as the last line of test
>>>> output.
>>>
>>> KUnit is currently including the test plan line only for subtests, as
>>> the current version doesn't actually know how many test suites will
>>> run in advance.
>>> This is something there's work underway to fix, though.
>> Sounds good.  You can just put the line at the bottom if it's
>> obnoxious to calculate ahead of time.
> 
> I thought that is not in the TAP spec?
> 
> I kind of like printing out ahead of time how many tests we expect to
> run, so if we crash we know how many tests weren't run.
> 
> In any case, until we get the change in that David is referencing, we
> cannot print out the test plan for the "super test" before or after
> because KUnit doesn't know when it is "done". So moving it to the
> bottom doesn't really help us.
> 
>> Does this mean that KUnit treats each sub-test as an individual test case
>> of the "super-test"?
> 
> Yes.
> 
> At the top level, we have all test suites. Each subtest in TAP is a
> test suite in KUnit. Each case in each subtest in TAP is a test case
> in KUnit.
> 
>> In results summaries for a super-test, are all sub-test cases counted,
>> or just the list of sub-tests?
> 
> Just the sub-tests. Each subtest is responsible for counting it's own cases:
> 
> https://github.com/isaacs/testanything.github.io/blob/tap14/tap-version-14-specification.md#subtests
> 
> Cheers
> 

Powered by blists - more mailing lists