RE: RFC - kernel selftest result documentation (KTAP)

[Bird, Tim]

> -----Original Message-----
> From: Brendan Higgins <brendanhiggins@xxxxxxxxxx>
> 
> On Mon, Jun 15, 2020 at 10:34 AM Bird, Tim <Tim.Bird@xxxxxxxx> wrote:
> >
> > > -----Original Message-----
> > > From: David Gow <davidgow@xxxxxxxxxx>
> > >
> > > On Thu, Jun 11, 2020 at 2:11 AM Bird, Tim <Tim.Bird@xxxxxxxx> 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.
I don't know if there's anyone left around to change their mind.

I have to agree with isaacs (who proposed TAP14 5 years ago),
that the TAP specification is in a weird state.

https://github.com/TestAnything/testanything.github.io/pull/36#issuecomment-566321633

There have been commits to the github respository by a few different
people recently (3 commits in the last 9 months).  But there's no body to approve or
disapprove of a new spec.

> 
> > 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 hate forks, but if we do go with declaring our own fork as KTAP,
then we should probably pull in the TAP14 spec as a starting point.
Since it has no home other than in a pull request, it seems a bit tentative.
We may need to put the spec in the kernel source or something.

I think we're definitely not doing anything with the yaml blocks at
the moment (or maybe ever), so there's one big point of departure.

> 
> > 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.

One thing that needs to be rationalized between KUnit and selftest
is the syntax for subtests.  KUnit follows the TAP14 spec, and starts
subtests with indented "# Subtest: name of the child test"
and selftests just indents the output from the child test, so it
starts with indented "TAP version 13".  One issue I have with the
TAP14/KUnit approach is that the output from the child is different
depending on whether the test is called in the context of another
test or not.

In KUnit, is it the parent test or the child test that prints out the
"# Subtest: ..." line?
 -- Tim


> 
> > > > 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