mbox series

[v2,0/1] lib: Convert UUID runtime test to KUnit

Message ID 20210609233730.164082-1-andrealmeid@collabora.com (mailing list archive)
Headers show
Series lib: Convert UUID runtime test to KUnit | expand

Message

André Almeida June 9, 2021, 11:37 p.m. UTC
Hi,

This patch converts existing UUID runtime test to use KUnit framework.

Below, there's a comparison between the old output format and the new
one. Keep in mind that even if KUnit seems very verbose, this is the
corner case where _every_ test has failed.

* This is how the current output looks like in success:

  test_uuid: all 18 tests passed

* And when it fails:

  test_uuid: conversion test #1 failed on LE data: 'c33f4995-3701-450e-9fbf-206a2e98e576'
  test_uuid: cmp test #2 failed on LE data: 'c33f4995-3701-450e-9fbf-206a2e98e576'
  test_uuid: cmp test #2 actual data: 'c33f4995-3701-450e-9fbf-206a2e98e576'
  test_uuid: conversion test #3 failed on BE data: 'c33f4995-3701-450e-9fbf-206a2e98e576'
  test_uuid: cmp test #4 failed on BE data: 'c33f4995-3701-450e-9fbf-206a2e98e576'
  test_uuid: cmp test #4 actual data: 'c33f4995-3701-450e-9fbf-206a2e98e576'
  test_uuid: conversion test #5 failed on LE data: '64b4371c-77c1-48f9-8221-29f054fc023b'
  test_uuid: cmp test #6 failed on LE data: '64b4371c-77c1-48f9-8221-29f054fc023b'
  test_uuid: cmp test #6 actual data: '64b4371c-77c1-48f9-8221-29f054fc023b'
  test_uuid: conversion test #7 failed on BE data: '64b4371c-77c1-48f9-8221-29f054fc023b'
  test_uuid: cmp test #8 failed on BE data: '64b4371c-77c1-48f9-8221-29f054fc023b'
  test_uuid: cmp test #8 actual data: '64b4371c-77c1-48f9-8221-29f054fc023b'
  test_uuid: conversion test #9 failed on LE data: '0cb4ddff-a545-4401-9d06-688af53e7f84'
  test_uuid: cmp test #10 failed on LE data: '0cb4ddff-a545-4401-9d06-688af53e7f84'
  test_uuid: cmp test #10 actual data: '0cb4ddff-a545-4401-9d06-688af53e7f84'
  test_uuid: conversion test #11 failed on BE data: '0cb4ddff-a545-4401-9d06-688af53e7f84'
  test_uuid: cmp test #12 failed on BE data: '0cb4ddff-a545-4401-9d06-688af53e7f84'
  test_uuid: cmp test #12 actual data: '0cb4ddff-a545-4401-9d06-688af53e7f84'
  test_uuid: negative test #13 passed on wrong LE data: 'c33f4995-3701-450e-9fbf206a2e98e576 '
  test_uuid: negative test #14 passed on wrong BE data: 'c33f4995-3701-450e-9fbf206a2e98e576 '
  test_uuid: negative test #15 passed on wrong LE data: '64b4371c-77c1-48f9-8221-29f054XX023b'
  test_uuid: negative test #16 passed on wrong BE data: '64b4371c-77c1-48f9-8221-29f054XX023b'
  test_uuid: negative test #17 passed on wrong LE data: '0cb4ddff-a545-4401-9d06-688af53e'
  test_uuid: negative test #18 passed on wrong BE data: '0cb4ddff-a545-4401-9d06-688af53e'
  test_uuid: failed 18 out of 18 tests


* Now, here's how it looks like with KUnit:

  ======== [PASSED] uuid ========
  [PASSED] uuid_correct_be
  [PASSED] uuid_correct_le
  [PASSED] uuid_wrong_be
  [PASSED] uuid_wrong_le

* And if every test fail with KUnit:

  ======== [FAILED] uuid ========
  [FAILED] uuid_correct_be
      # uuid_correct_be: ASSERTION FAILED at lib/test_uuid.c:57
      Expected uuid_parse(data->uuid, &be) == 1, but
          uuid_parse(data->uuid, &be) == 0
  
  failed to parse 'c33f4995-3701-450e-9fbf-206a2e98e576'
      # uuid_correct_be: not ok 1 - c33f4995-3701-450e-9fbf-206a2e98e576
      # uuid_correct_be: ASSERTION FAILED at lib/test_uuid.c:57
      Expected uuid_parse(data->uuid, &be) == 1, but
          uuid_parse(data->uuid, &be) == 0
  
  failed to parse '64b4371c-77c1-48f9-8221-29f054fc023b'
      # uuid_correct_be: not ok 2 - 64b4371c-77c1-48f9-8221-29f054fc023b
      # uuid_correct_be: ASSERTION FAILED at lib/test_uuid.c:57
      Expected uuid_parse(data->uuid, &be) == 1, but
          uuid_parse(data->uuid, &be) == 0
  
  failed to parse '0cb4ddff-a545-4401-9d06-688af53e7f84'
      # uuid_correct_be: not ok 3 - 0cb4ddff-a545-4401-9d06-688af53e7f84
      not ok 1 - uuid_correct_be
  
  [FAILED] uuid_correct_le
      # uuid_correct_le: ASSERTION FAILED at lib/test_uuid.c:46
      Expected guid_parse(data->uuid, &le) == 1, but
          guid_parse(data->uuid, &le) == 0
  
  failed to parse 'c33f4995-3701-450e-9fbf-206a2e98e576'
      # uuid_correct_le: not ok 1 - c33f4995-3701-450e-9fbf-206a2e98e576
      # uuid_correct_le: ASSERTION FAILED at lib/test_uuid.c:46
      Expected guid_parse(data->uuid, &le) == 1, but
          guid_parse(data->uuid, &le) == 0
  
  failed to parse '64b4371c-77c1-48f9-8221-29f054fc023b'
      # uuid_correct_le: not ok 2 - 64b4371c-77c1-48f9-8221-29f054fc023b
      # uuid_correct_le: ASSERTION FAILED at lib/test_uuid.c:46
      Expected guid_parse(data->uuid, &le) == 1, but
          guid_parse(data->uuid, &le) == 0
  
  failed to parse '0cb4ddff-a545-4401-9d06-688af53e7f84'
      # uuid_correct_le: not ok 3 - 0cb4ddff-a545-4401-9d06-688af53e7f84
      not ok 2 - uuid_correct_le
  
  [FAILED] uuid_wrong_be
      # uuid_wrong_be: ASSERTION FAILED at lib/test_uuid.c:77
      Expected uuid_parse(*data, &be) == 0, but
          uuid_parse(*data, &be) == -22
  
  parsing of 'c33f4995-3701-450e-9fbf206a2e98e576 ' should've failed
      # uuid_wrong_be: not ok 1 - c33f4995-3701-450e-9fbf206a2e98e576
      # uuid_wrong_be: ASSERTION FAILED at lib/test_uuid.c:77
      Expected uuid_parse(*data, &be) == 0, but
          uuid_parse(*data, &be) == -22
  
  parsing of '64b4371c-77c1-48f9-8221-29f054XX023b' should've failed
      # uuid_wrong_be: not ok 2 - 64b4371c-77c1-48f9-8221-29f054XX023b
      # uuid_wrong_be: ASSERTION FAILED at lib/test_uuid.c:77
      Expected uuid_parse(*data, &be) == 0, but
          uuid_parse(*data, &be) == -22
  
  parsing of '0cb4ddff-a545-4401-9d06-688af53e' should've failed
      # uuid_wrong_be: not ok 3 - 0cb4ddff-a545-4401-9d06-688af53e
      not ok 3 - uuid_wrong_be
  
  [FAILED] uuid_wrong_le
      # uuid_wrong_le: ASSERTION FAILED at lib/test_uuid.c:68
      Expected guid_parse(*data, &le) == 0, but
          guid_parse(*data, &le) == -22
  
  parsing of 'c33f4995-3701-450e-9fbf206a2e98e576 ' should've failed
      # uuid_wrong_le: not ok 1 - c33f4995-3701-450e-9fbf206a2e98e576
      # uuid_wrong_le: ASSERTION FAILED at lib/test_uuid.c:68
      Expected guid_parse(*data, &le) == 0, but
          guid_parse(*data, &le) == -22
  
  parsing of '64b4371c-77c1-48f9-8221-29f054XX023b' should've failed
      # uuid_wrong_le: not ok 2 - 64b4371c-77c1-48f9-8221-29f054XX023b
      # uuid_wrong_le: ASSERTION FAILED at lib/test_uuid.c:68
      Expected guid_parse(*data, &le) == 0, but
          guid_parse(*data, &le) == -22
  
  parsing of '0cb4ddff-a545-4401-9d06-688af53e' should've failed
      # uuid_wrong_le: not ok 3 - 0cb4ddff-a545-4401-9d06-688af53e
      not ok 4 - uuid_wrong_le

Changes from v1:
 - Test suite name: uuid_test -> uuid
 - Config name: TEST_UUID -> UUID_KUNIT_TEST
 - Config entry in the Kconfig file left where it is
 - Converted tests to use _MSG variant

André Almeida (1):
  lib: Convert UUID runtime test to KUnit

 lib/Kconfig.debug |  11 +++-
 lib/Makefile      |   2 +-
 lib/test_uuid.c   | 137 +++++++++++++++++++---------------------------
 3 files changed, 67 insertions(+), 83 deletions(-)

Comments

Andy Shevchenko June 10, 2021, 9:13 a.m. UTC | #1
On Wed, Jun 09, 2021 at 08:37:29PM -0300, André Almeida wrote:
> Hi,
> 
> This patch converts existing UUID runtime test to use KUnit framework.
> 
> Below, there's a comparison between the old output format and the new
> one. Keep in mind that even if KUnit seems very verbose, this is the
> corner case where _every_ test has failed.
> 
> * This is how the current output looks like in success:
> 
>   test_uuid: all 18 tests passed
> 
> * And when it fails:
> 
>   test_uuid: conversion test #1 failed on LE data: 'c33f4995-3701-450e-9fbf-206a2e98e576'
>   test_uuid: cmp test #2 failed on LE data: 'c33f4995-3701-450e-9fbf-206a2e98e576'
>   test_uuid: cmp test #2 actual data: 'c33f4995-3701-450e-9fbf-206a2e98e576'
>   test_uuid: conversion test #3 failed on BE data: 'c33f4995-3701-450e-9fbf-206a2e98e576'
>   test_uuid: cmp test #4 failed on BE data: 'c33f4995-3701-450e-9fbf-206a2e98e576'
>   test_uuid: cmp test #4 actual data: 'c33f4995-3701-450e-9fbf-206a2e98e576'
>   test_uuid: conversion test #5 failed on LE data: '64b4371c-77c1-48f9-8221-29f054fc023b'
>   test_uuid: cmp test #6 failed on LE data: '64b4371c-77c1-48f9-8221-29f054fc023b'
>   test_uuid: cmp test #6 actual data: '64b4371c-77c1-48f9-8221-29f054fc023b'
>   test_uuid: conversion test #7 failed on BE data: '64b4371c-77c1-48f9-8221-29f054fc023b'
>   test_uuid: cmp test #8 failed on BE data: '64b4371c-77c1-48f9-8221-29f054fc023b'
>   test_uuid: cmp test #8 actual data: '64b4371c-77c1-48f9-8221-29f054fc023b'
>   test_uuid: conversion test #9 failed on LE data: '0cb4ddff-a545-4401-9d06-688af53e7f84'
>   test_uuid: cmp test #10 failed on LE data: '0cb4ddff-a545-4401-9d06-688af53e7f84'
>   test_uuid: cmp test #10 actual data: '0cb4ddff-a545-4401-9d06-688af53e7f84'
>   test_uuid: conversion test #11 failed on BE data: '0cb4ddff-a545-4401-9d06-688af53e7f84'
>   test_uuid: cmp test #12 failed on BE data: '0cb4ddff-a545-4401-9d06-688af53e7f84'
>   test_uuid: cmp test #12 actual data: '0cb4ddff-a545-4401-9d06-688af53e7f84'
>   test_uuid: negative test #13 passed on wrong LE data: 'c33f4995-3701-450e-9fbf206a2e98e576 '
>   test_uuid: negative test #14 passed on wrong BE data: 'c33f4995-3701-450e-9fbf206a2e98e576 '
>   test_uuid: negative test #15 passed on wrong LE data: '64b4371c-77c1-48f9-8221-29f054XX023b'
>   test_uuid: negative test #16 passed on wrong BE data: '64b4371c-77c1-48f9-8221-29f054XX023b'
>   test_uuid: negative test #17 passed on wrong LE data: '0cb4ddff-a545-4401-9d06-688af53e'
>   test_uuid: negative test #18 passed on wrong BE data: '0cb4ddff-a545-4401-9d06-688af53e'
>   test_uuid: failed 18 out of 18 tests
> 
> 
> * Now, here's how it looks like with KUnit:
> 
>   ======== [PASSED] uuid ========
>   [PASSED] uuid_correct_be
>   [PASSED] uuid_correct_le
>   [PASSED] uuid_wrong_be
>   [PASSED] uuid_wrong_le
> 
> * And if every test fail with KUnit:
> 
>   ======== [FAILED] uuid ========
>   [FAILED] uuid_correct_be
>       # uuid_correct_be: ASSERTION FAILED at lib/test_uuid.c:57
>       Expected uuid_parse(data->uuid, &be) == 1, but
>           uuid_parse(data->uuid, &be) == 0
>   
>   failed to parse 'c33f4995-3701-450e-9fbf-206a2e98e576'
>       # uuid_correct_be: not ok 1 - c33f4995-3701-450e-9fbf-206a2e98e576
>       # uuid_correct_be: ASSERTION FAILED at lib/test_uuid.c:57
>       Expected uuid_parse(data->uuid, &be) == 1, but
>           uuid_parse(data->uuid, &be) == 0
>   
>   failed to parse '64b4371c-77c1-48f9-8221-29f054fc023b'
>       # uuid_correct_be: not ok 2 - 64b4371c-77c1-48f9-8221-29f054fc023b
>       # uuid_correct_be: ASSERTION FAILED at lib/test_uuid.c:57
>       Expected uuid_parse(data->uuid, &be) == 1, but
>           uuid_parse(data->uuid, &be) == 0
>   
>   failed to parse '0cb4ddff-a545-4401-9d06-688af53e7f84'
>       # uuid_correct_be: not ok 3 - 0cb4ddff-a545-4401-9d06-688af53e7f84
>       not ok 1 - uuid_correct_be
>   
>   [FAILED] uuid_correct_le
>       # uuid_correct_le: ASSERTION FAILED at lib/test_uuid.c:46
>       Expected guid_parse(data->uuid, &le) == 1, but
>           guid_parse(data->uuid, &le) == 0
>   
>   failed to parse 'c33f4995-3701-450e-9fbf-206a2e98e576'
>       # uuid_correct_le: not ok 1 - c33f4995-3701-450e-9fbf-206a2e98e576
>       # uuid_correct_le: ASSERTION FAILED at lib/test_uuid.c:46
>       Expected guid_parse(data->uuid, &le) == 1, but
>           guid_parse(data->uuid, &le) == 0
>   
>   failed to parse '64b4371c-77c1-48f9-8221-29f054fc023b'
>       # uuid_correct_le: not ok 2 - 64b4371c-77c1-48f9-8221-29f054fc023b
>       # uuid_correct_le: ASSERTION FAILED at lib/test_uuid.c:46
>       Expected guid_parse(data->uuid, &le) == 1, but
>           guid_parse(data->uuid, &le) == 0
>   
>   failed to parse '0cb4ddff-a545-4401-9d06-688af53e7f84'
>       # uuid_correct_le: not ok 3 - 0cb4ddff-a545-4401-9d06-688af53e7f84
>       not ok 2 - uuid_correct_le
>   
>   [FAILED] uuid_wrong_be
>       # uuid_wrong_be: ASSERTION FAILED at lib/test_uuid.c:77
>       Expected uuid_parse(*data, &be) == 0, but
>           uuid_parse(*data, &be) == -22
>   
>   parsing of 'c33f4995-3701-450e-9fbf206a2e98e576 ' should've failed
>       # uuid_wrong_be: not ok 1 - c33f4995-3701-450e-9fbf206a2e98e576
>       # uuid_wrong_be: ASSERTION FAILED at lib/test_uuid.c:77
>       Expected uuid_parse(*data, &be) == 0, but
>           uuid_parse(*data, &be) == -22
>   
>   parsing of '64b4371c-77c1-48f9-8221-29f054XX023b' should've failed
>       # uuid_wrong_be: not ok 2 - 64b4371c-77c1-48f9-8221-29f054XX023b
>       # uuid_wrong_be: ASSERTION FAILED at lib/test_uuid.c:77
>       Expected uuid_parse(*data, &be) == 0, but
>           uuid_parse(*data, &be) == -22
>   
>   parsing of '0cb4ddff-a545-4401-9d06-688af53e' should've failed
>       # uuid_wrong_be: not ok 3 - 0cb4ddff-a545-4401-9d06-688af53e
>       not ok 3 - uuid_wrong_be
>   
>   [FAILED] uuid_wrong_le
>       # uuid_wrong_le: ASSERTION FAILED at lib/test_uuid.c:68
>       Expected guid_parse(*data, &le) == 0, but
>           guid_parse(*data, &le) == -22
>   
>   parsing of 'c33f4995-3701-450e-9fbf206a2e98e576 ' should've failed
>       # uuid_wrong_le: not ok 1 - c33f4995-3701-450e-9fbf206a2e98e576
>       # uuid_wrong_le: ASSERTION FAILED at lib/test_uuid.c:68
>       Expected guid_parse(*data, &le) == 0, but
>           guid_parse(*data, &le) == -22
>   
>   parsing of '64b4371c-77c1-48f9-8221-29f054XX023b' should've failed
>       # uuid_wrong_le: not ok 2 - 64b4371c-77c1-48f9-8221-29f054XX023b
>       # uuid_wrong_le: ASSERTION FAILED at lib/test_uuid.c:68
>       Expected guid_parse(*data, &le) == 0, but
>           guid_parse(*data, &le) == -22
>   
>   parsing of '0cb4ddff-a545-4401-9d06-688af53e' should've failed
>       # uuid_wrong_le: not ok 3 - 0cb4ddff-a545-4401-9d06-688af53e
>       not ok 4 - uuid_wrong_le

Thanks!

It's not your fault but I think we need to defer this until KUnit gains support
of the run statistics. My guts telling me if we allow more and more conversions
like this the point will vanish and nobody will care.

I like the code, but I can give my tag after KUnit prints some kind of this:

 * This is how the current output looks like in success:

   test_uuid: all 18 tests passed

 * And when it fails:

   test_uuid: failed 18 out of 18 tests

> Changes from v1:
>  - Test suite name: uuid_test -> uuid
>  - Config name: TEST_UUID -> UUID_KUNIT_TEST
>  - Config entry in the Kconfig file left where it is
>  - Converted tests to use _MSG variant
> 
> André Almeida (1):
>   lib: Convert UUID runtime test to KUnit
> 
>  lib/Kconfig.debug |  11 +++-
>  lib/Makefile      |   2 +-
>  lib/test_uuid.c   | 137 +++++++++++++++++++---------------------------
>  3 files changed, 67 insertions(+), 83 deletions(-)
> 
> -- 
> 2.31.1
>
David Gow June 10, 2021, 11:53 a.m. UTC | #2
On Thu, Jun 10, 2021 at 5:14 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Wed, Jun 09, 2021 at 08:37:29PM -0300, André Almeida wrote:
> > Hi,
> >
> > This patch converts existing UUID runtime test to use KUnit framework.
> >
> > Below, there's a comparison between the old output format and the new
> > one. Keep in mind that even if KUnit seems very verbose, this is the
> > corner case where _every_ test has failed.
> >
> > * This is how the current output looks like in success:
> >
> >   test_uuid: all 18 tests passed
> >
> > * And when it fails:
> >
> >   test_uuid: conversion test #1 failed on LE data: 'c33f4995-3701-450e-9fbf-206a2e98e576'
> >   test_uuid: cmp test #2 failed on LE data: 'c33f4995-3701-450e-9fbf-206a2e98e576'
> >   test_uuid: cmp test #2 actual data: 'c33f4995-3701-450e-9fbf-206a2e98e576'
> >   test_uuid: conversion test #3 failed on BE data: 'c33f4995-3701-450e-9fbf-206a2e98e576'
> >   test_uuid: cmp test #4 failed on BE data: 'c33f4995-3701-450e-9fbf-206a2e98e576'
> >   test_uuid: cmp test #4 actual data: 'c33f4995-3701-450e-9fbf-206a2e98e576'
> >   test_uuid: conversion test #5 failed on LE data: '64b4371c-77c1-48f9-8221-29f054fc023b'
> >   test_uuid: cmp test #6 failed on LE data: '64b4371c-77c1-48f9-8221-29f054fc023b'
> >   test_uuid: cmp test #6 actual data: '64b4371c-77c1-48f9-8221-29f054fc023b'
> >   test_uuid: conversion test #7 failed on BE data: '64b4371c-77c1-48f9-8221-29f054fc023b'
> >   test_uuid: cmp test #8 failed on BE data: '64b4371c-77c1-48f9-8221-29f054fc023b'
> >   test_uuid: cmp test #8 actual data: '64b4371c-77c1-48f9-8221-29f054fc023b'
> >   test_uuid: conversion test #9 failed on LE data: '0cb4ddff-a545-4401-9d06-688af53e7f84'
> >   test_uuid: cmp test #10 failed on LE data: '0cb4ddff-a545-4401-9d06-688af53e7f84'
> >   test_uuid: cmp test #10 actual data: '0cb4ddff-a545-4401-9d06-688af53e7f84'
> >   test_uuid: conversion test #11 failed on BE data: '0cb4ddff-a545-4401-9d06-688af53e7f84'
> >   test_uuid: cmp test #12 failed on BE data: '0cb4ddff-a545-4401-9d06-688af53e7f84'
> >   test_uuid: cmp test #12 actual data: '0cb4ddff-a545-4401-9d06-688af53e7f84'
> >   test_uuid: negative test #13 passed on wrong LE data: 'c33f4995-3701-450e-9fbf206a2e98e576 '
> >   test_uuid: negative test #14 passed on wrong BE data: 'c33f4995-3701-450e-9fbf206a2e98e576 '
> >   test_uuid: negative test #15 passed on wrong LE data: '64b4371c-77c1-48f9-8221-29f054XX023b'
> >   test_uuid: negative test #16 passed on wrong BE data: '64b4371c-77c1-48f9-8221-29f054XX023b'
> >   test_uuid: negative test #17 passed on wrong LE data: '0cb4ddff-a545-4401-9d06-688af53e'
> >   test_uuid: negative test #18 passed on wrong BE data: '0cb4ddff-a545-4401-9d06-688af53e'
> >   test_uuid: failed 18 out of 18 tests
> >
> >
> > * Now, here's how it looks like with KUnit:
> >
> >   ======== [PASSED] uuid ========
> >   [PASSED] uuid_correct_be
> >   [PASSED] uuid_correct_le
> >   [PASSED] uuid_wrong_be
> >   [PASSED] uuid_wrong_le
> >
> > * And if every test fail with KUnit:
> >
> >   ======== [FAILED] uuid ========
> >   [FAILED] uuid_correct_be
> >       # uuid_correct_be: ASSERTION FAILED at lib/test_uuid.c:57
> >       Expected uuid_parse(data->uuid, &be) == 1, but
> >           uuid_parse(data->uuid, &be) == 0
> >
> >   failed to parse 'c33f4995-3701-450e-9fbf-206a2e98e576'
> >       # uuid_correct_be: not ok 1 - c33f4995-3701-450e-9fbf-206a2e98e576
> >       # uuid_correct_be: ASSERTION FAILED at lib/test_uuid.c:57
> >       Expected uuid_parse(data->uuid, &be) == 1, but
> >           uuid_parse(data->uuid, &be) == 0
> >
> >   failed to parse '64b4371c-77c1-48f9-8221-29f054fc023b'
> >       # uuid_correct_be: not ok 2 - 64b4371c-77c1-48f9-8221-29f054fc023b
> >       # uuid_correct_be: ASSERTION FAILED at lib/test_uuid.c:57
> >       Expected uuid_parse(data->uuid, &be) == 1, but
> >           uuid_parse(data->uuid, &be) == 0
> >
> >   failed to parse '0cb4ddff-a545-4401-9d06-688af53e7f84'
> >       # uuid_correct_be: not ok 3 - 0cb4ddff-a545-4401-9d06-688af53e7f84
> >       not ok 1 - uuid_correct_be
> >
> >   [FAILED] uuid_correct_le
> >       # uuid_correct_le: ASSERTION FAILED at lib/test_uuid.c:46
> >       Expected guid_parse(data->uuid, &le) == 1, but
> >           guid_parse(data->uuid, &le) == 0
> >
> >   failed to parse 'c33f4995-3701-450e-9fbf-206a2e98e576'
> >       # uuid_correct_le: not ok 1 - c33f4995-3701-450e-9fbf-206a2e98e576
> >       # uuid_correct_le: ASSERTION FAILED at lib/test_uuid.c:46
> >       Expected guid_parse(data->uuid, &le) == 1, but
> >           guid_parse(data->uuid, &le) == 0
> >
> >   failed to parse '64b4371c-77c1-48f9-8221-29f054fc023b'
> >       # uuid_correct_le: not ok 2 - 64b4371c-77c1-48f9-8221-29f054fc023b
> >       # uuid_correct_le: ASSERTION FAILED at lib/test_uuid.c:46
> >       Expected guid_parse(data->uuid, &le) == 1, but
> >           guid_parse(data->uuid, &le) == 0
> >
> >   failed to parse '0cb4ddff-a545-4401-9d06-688af53e7f84'
> >       # uuid_correct_le: not ok 3 - 0cb4ddff-a545-4401-9d06-688af53e7f84
> >       not ok 2 - uuid_correct_le
> >
> >   [FAILED] uuid_wrong_be
> >       # uuid_wrong_be: ASSERTION FAILED at lib/test_uuid.c:77
> >       Expected uuid_parse(*data, &be) == 0, but
> >           uuid_parse(*data, &be) == -22
> >
> >   parsing of 'c33f4995-3701-450e-9fbf206a2e98e576 ' should've failed
> >       # uuid_wrong_be: not ok 1 - c33f4995-3701-450e-9fbf206a2e98e576
> >       # uuid_wrong_be: ASSERTION FAILED at lib/test_uuid.c:77
> >       Expected uuid_parse(*data, &be) == 0, but
> >           uuid_parse(*data, &be) == -22
> >
> >   parsing of '64b4371c-77c1-48f9-8221-29f054XX023b' should've failed
> >       # uuid_wrong_be: not ok 2 - 64b4371c-77c1-48f9-8221-29f054XX023b
> >       # uuid_wrong_be: ASSERTION FAILED at lib/test_uuid.c:77
> >       Expected uuid_parse(*data, &be) == 0, but
> >           uuid_parse(*data, &be) == -22
> >
> >   parsing of '0cb4ddff-a545-4401-9d06-688af53e' should've failed
> >       # uuid_wrong_be: not ok 3 - 0cb4ddff-a545-4401-9d06-688af53e
> >       not ok 3 - uuid_wrong_be
> >
> >   [FAILED] uuid_wrong_le
> >       # uuid_wrong_le: ASSERTION FAILED at lib/test_uuid.c:68
> >       Expected guid_parse(*data, &le) == 0, but
> >           guid_parse(*data, &le) == -22
> >
> >   parsing of 'c33f4995-3701-450e-9fbf206a2e98e576 ' should've failed
> >       # uuid_wrong_le: not ok 1 - c33f4995-3701-450e-9fbf206a2e98e576
> >       # uuid_wrong_le: ASSERTION FAILED at lib/test_uuid.c:68
> >       Expected guid_parse(*data, &le) == 0, but
> >           guid_parse(*data, &le) == -22
> >
> >   parsing of '64b4371c-77c1-48f9-8221-29f054XX023b' should've failed
> >       # uuid_wrong_le: not ok 2 - 64b4371c-77c1-48f9-8221-29f054XX023b
> >       # uuid_wrong_le: ASSERTION FAILED at lib/test_uuid.c:68
> >       Expected guid_parse(*data, &le) == 0, but
> >           guid_parse(*data, &le) == -22
> >
> >   parsing of '0cb4ddff-a545-4401-9d06-688af53e' should've failed
> >       # uuid_wrong_le: not ok 3 - 0cb4ddff-a545-4401-9d06-688af53e
> >       not ok 4 - uuid_wrong_le

Note that this output is from the kunit_tool script, which parses the
test output.
It does include a summary line:
[04:41:01] Testing complete. 4 tests run. 0 failed. 0 crashed.

Note that this does only count the number of "tests" run --- the
individual UUIDs are parameters to the same test, so aren't counted
independently by the wrapper at the moment.

That being said, the raw output looks like this (all tests passed):
TAP version 14
1..1
   # Subtest: uuid
   1..4
   # uuid_correct_be: ok 1 - c33f4995-3701-450e-9fbf-206a2e98e576
   # uuid_correct_be: ok 2 - 64b4371c-77c1-48f9-8221-29f054fc023b
   # uuid_correct_be: ok 3 - 0cb4ddff-a545-4401-9d06-688af53e7f84
   ok 1 - uuid_correct_be
   # uuid_correct_le: ok 1 - c33f4995-3701-450e-9fbf-206a2e98e576
   # uuid_correct_le: ok 2 - 64b4371c-77c1-48f9-8221-29f054fc023b
   # uuid_correct_le: ok 3 - 0cb4ddff-a545-4401-9d06-688af53e7f84
   ok 2 - uuid_correct_le
   # uuid_wrong_be: ok 1 - c33f4995-3701-450e-9fbf206a2e98e576
   # uuid_wrong_be: ok 2 - 64b4371c-77c1-48f9-8221-29f054XX023b
   # uuid_wrong_be: ok 3 - 0cb4ddff-a545-4401-9d06-688af53e
   ok 3 - uuid_wrong_be
   # uuid_wrong_le: ok 1 - c33f4995-3701-450e-9fbf206a2e98e576
   # uuid_wrong_le: ok 2 - 64b4371c-77c1-48f9-8221-29f054XX023b
   # uuid_wrong_le: ok 3 - 0cb4ddff-a545-4401-9d06-688af53e
   ok 4 - uuid_wrong_le
ok 1 - uuid

A test which failed could look like this:
    # uuid_correct_le: ASSERTION FAILED at lib/test_uuid.c:46
   Expected guid_parse(data->uuid, &le) == 0, but
       guid_parse(data->uuid, &le) == -22

failed to parse 'c33f499x5-3701-450e-9fbf-206a2e98e576'
   # uuid_correct_le: not ok 1 - c33f499x5-3701-450e-9fbf-206a2e98e576
   # uuid_correct_le: ok 2 - 64b4371c-77c1-48f9-8221-29f054fc023b
   # uuid_correct_le: ok 3 - 0cb4ddff-a545-4401-9d06-688af53e7f84
   not ok 2 - uuid_correct_le

>
> Thanks!
>
> It's not your fault but I think we need to defer this until KUnit gains support
> of the run statistics. My guts telling me if we allow more and more conversions
> like this the point will vanish and nobody will care.

Did the test statistics patch we sent out before meet your expectations?
https://patchwork.kernel.org/project/linux-kselftest/patch/20201211072319.533803-1-davidgow@google.com/

If so, we can tidy it up and try to push it through straight away, we
were just waiting for a review from someone who wanted the feature.


> I like the code, but I can give my tag after KUnit prints some kind of this:
>
>  * This is how the current output looks like in success:
>
>    test_uuid: all 18 tests passed
>
>  * And when it fails:
>
>    test_uuid: failed 18 out of 18 tests
>

There are some small restrictions on the exact format KUnit can use
for this if we want to continue to match the (K)TAP specification
which is being adopted by kselftest. The patch linked above should
give something formatted like:

# test_uuid: (0 / 4) tests failed (0 / 12 test parameters)

Would that work for you?

Cheers,
-- David
Andy Shevchenko June 10, 2021, 12:39 p.m. UTC | #3
On Thu, Jun 10, 2021 at 2:54 PM David Gow <davidgow@google.com> wrote:
> On Thu, Jun 10, 2021 at 5:14 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Wed, Jun 09, 2021 at 08:37:29PM -0300, André Almeida wrote:

...

> Note that this output is from the kunit_tool script, which parses the
> test output.
> It does include a summary line:
> [04:41:01] Testing complete. 4 tests run. 0 failed. 0 crashed.

> Note that this does only count the number of "tests" run --- the
> individual UUIDs are parameters to the same test, so aren't counted
> independently by the wrapper at the moment.
>
> That being said, the raw output looks like this (all tests passed):
> TAP version 14
> 1..1
>    # Subtest: uuid
>    1..4
>    # uuid_correct_be: ok 1 - c33f4995-3701-450e-9fbf-206a2e98e576
>    # uuid_correct_be: ok 2 - 64b4371c-77c1-48f9-8221-29f054fc023b
>    # uuid_correct_be: ok 3 - 0cb4ddff-a545-4401-9d06-688af53e7f84
>    ok 1 - uuid_correct_be
>    # uuid_correct_le: ok 1 - c33f4995-3701-450e-9fbf-206a2e98e576
>    # uuid_correct_le: ok 2 - 64b4371c-77c1-48f9-8221-29f054fc023b
>    # uuid_correct_le: ok 3 - 0cb4ddff-a545-4401-9d06-688af53e7f84
>    ok 2 - uuid_correct_le
>    # uuid_wrong_be: ok 1 - c33f4995-3701-450e-9fbf206a2e98e576
>    # uuid_wrong_be: ok 2 - 64b4371c-77c1-48f9-8221-29f054XX023b
>    # uuid_wrong_be: ok 3 - 0cb4ddff-a545-4401-9d06-688af53e
>    ok 3 - uuid_wrong_be
>    # uuid_wrong_le: ok 1 - c33f4995-3701-450e-9fbf206a2e98e576
>    # uuid_wrong_le: ok 2 - 64b4371c-77c1-48f9-8221-29f054XX023b
>    # uuid_wrong_le: ok 3 - 0cb4ddff-a545-4401-9d06-688af53e
>    ok 4 - uuid_wrong_le
> ok 1 - uuid
>
> A test which failed could look like this:
>     # uuid_correct_le: ASSERTION FAILED at lib/test_uuid.c:46
>    Expected guid_parse(data->uuid, &le) == 0, but
>        guid_parse(data->uuid, &le) == -22
>
> failed to parse 'c33f499x5-3701-450e-9fbf-206a2e98e576'
>    # uuid_correct_le: not ok 1 - c33f499x5-3701-450e-9fbf-206a2e98e576
>    # uuid_correct_le: ok 2 - 64b4371c-77c1-48f9-8221-29f054fc023b
>    # uuid_correct_le: ok 3 - 0cb4ddff-a545-4401-9d06-688af53e7f84
>    not ok 2 - uuid_correct_le
>
> >
> > Thanks!
> >
> > It's not your fault but I think we need to defer this until KUnit gains support
> > of the run statistics. My guts telling me if we allow more and more conversions
> > like this the point will vanish and nobody will care.
>
> Did the test statistics patch we sent out before meet your expectations?
> https://patchwork.kernel.org/project/linux-kselftest/patch/20201211072319.533803-1-davidgow@google.com/

Let me look at it at some point.

> If so, we can tidy it up and try to push it through straight away, we
> were just waiting for a review from someone who wanted the feature.
>
>
> > I like the code, but I can give my tag after KUnit prints some kind of this:
> >
> >  * This is how the current output looks like in success:
> >
> >    test_uuid: all 18 tests passed
> >
> >  * And when it fails:
> >
> >    test_uuid: failed 18 out of 18 tests
> >
>
> There are some small restrictions on the exact format KUnit can use
> for this if we want to continue to match the (K)TAP specification
> which is being adopted by kselftest. The patch linked above should
> give something formatted like:
>
> # test_uuid: (0 / 4) tests failed (0 / 12 test parameters)
>
> Would that work for you?

Can you decode it for me, please?

(Assuming that the above question arisen, perhaps some rephrasing is
needed. The idea that user should have clear understanding on how many
test cases were run and how many of them successfully finished or
failed. According to this thread I have to see the cumulative number
of 18 (either as one number or sum over test cases or how you call
them, I see 4 here).
André Almeida June 10, 2021, 1:08 p.m. UTC | #4
Às 09:39 de 10/06/21, Andy Shevchenko escreveu:
> On Thu, Jun 10, 2021 at 2:54 PM David Gow <davidgow@google.com> wrote:
>> On Thu, Jun 10, 2021 at 5:14 PM Andy Shevchenko
>> <andriy.shevchenko@linux.intel.com> wrote:
>>> On Wed, Jun 09, 2021 at 08:37:29PM -0300, André Almeida wrote:
> 
> ...
> 
>> Note that this output is from the kunit_tool script, which parses the
>> test output.
>> It does include a summary line:
>> [04:41:01] Testing complete. 4 tests run. 0 failed. 0 crashed.
> 
>> Note that this does only count the number of "tests" run --- the
>> individual UUIDs are parameters to the same test, so aren't counted
>> independently by the wrapper at the moment.
>>
>> That being said, the raw output looks like this (all tests passed):
>> TAP version 14
>> 1..1
>>    # Subtest: uuid
>>    1..4
>>    # uuid_correct_be: ok 1 - c33f4995-3701-450e-9fbf-206a2e98e576
>>    # uuid_correct_be: ok 2 - 64b4371c-77c1-48f9-8221-29f054fc023b
>>    # uuid_correct_be: ok 3 - 0cb4ddff-a545-4401-9d06-688af53e7f84
>>    ok 1 - uuid_correct_be
>>    # uuid_correct_le: ok 1 - c33f4995-3701-450e-9fbf-206a2e98e576
>>    # uuid_correct_le: ok 2 - 64b4371c-77c1-48f9-8221-29f054fc023b
>>    # uuid_correct_le: ok 3 - 0cb4ddff-a545-4401-9d06-688af53e7f84
>>    ok 2 - uuid_correct_le
>>    # uuid_wrong_be: ok 1 - c33f4995-3701-450e-9fbf206a2e98e576
>>    # uuid_wrong_be: ok 2 - 64b4371c-77c1-48f9-8221-29f054XX023b
>>    # uuid_wrong_be: ok 3 - 0cb4ddff-a545-4401-9d06-688af53e
>>    ok 3 - uuid_wrong_be
>>    # uuid_wrong_le: ok 1 - c33f4995-3701-450e-9fbf206a2e98e576
>>    # uuid_wrong_le: ok 2 - 64b4371c-77c1-48f9-8221-29f054XX023b
>>    # uuid_wrong_le: ok 3 - 0cb4ddff-a545-4401-9d06-688af53e
>>    ok 4 - uuid_wrong_le
>> ok 1 - uuid
>>
>> A test which failed could look like this:
>>     # uuid_correct_le: ASSERTION FAILED at lib/test_uuid.c:46
>>    Expected guid_parse(data->uuid, &le) == 0, but
>>        guid_parse(data->uuid, &le) == -22
>>
>> failed to parse 'c33f499x5-3701-450e-9fbf-206a2e98e576'
>>    # uuid_correct_le: not ok 1 - c33f499x5-3701-450e-9fbf-206a2e98e576
>>    # uuid_correct_le: ok 2 - 64b4371c-77c1-48f9-8221-29f054fc023b
>>    # uuid_correct_le: ok 3 - 0cb4ddff-a545-4401-9d06-688af53e7f84
>>    not ok 2 - uuid_correct_le
>>
>>>
>>> Thanks!
>>>
>>> It's not your fault but I think we need to defer this until KUnit gains support
>>> of the run statistics. My guts telling me if we allow more and more conversions
>>> like this the point will vanish and nobody will care.
>>
>> Did the test statistics patch we sent out before meet your expectations?
>> https://patchwork.kernel.org/project/linux-kselftest/patch/20201211072319.533803-1-davidgow@google.com/
> 
> Let me look at it at some point.
> 
>> If so, we can tidy it up and try to push it through straight away, we
>> were just waiting for a review from someone who wanted the feature.
>>
>>
>>> I like the code, but I can give my tag after KUnit prints some kind of this:
>>>
>>>  * This is how the current output looks like in success:
>>>
>>>    test_uuid: all 18 tests passed
>>>
>>>  * And when it fails:
>>>
>>>    test_uuid: failed 18 out of 18 tests
>>>
>>
>> There are some small restrictions on the exact format KUnit can use
>> for this if we want to continue to match the (K)TAP specification
>> which is being adopted by kselftest. The patch linked above should
>> give something formatted like:
>>
>> # test_uuid: (0 / 4) tests failed (0 / 12 test parameters)
>>
>> Would that work for you?
> 
> Can you decode it for me, please?
> 
> (Assuming that the above question arisen, perhaps some rephrasing is
> needed. The idea that user should have clear understanding on how many
> test cases were run and how many of them successfully finished or
> failed. According to this thread I have to see the cumulative number
> of 18 (either as one number or sum over test cases or how you call
> them, I see 4 here).
> 
> 

In the original code, each `if(uuid/guid_parse/equal)` was considered as
a test, so there were 4 tests for the 3 correct inputs and 2 tests for
the 3 wrong inputs: 4 * 3 + 2 * 3 = 18 tests.

In my patch, I've organized in a different way, with 4 test cases:

- A test case for guid_parse and guid_equal for correct inputs
- A test case for uuid_parse and uuid_equal for correct inputs
- A test case for guid_parse for incorrect inputs
- A test case for uuid_parse for incorrect inputs

So now we have 4 test cases, instead of the 6 test cases in the original
code, because I've united _parse and _equal in a single test case. Given
that each test has 3 parameters, this is why we see 12 test parameters
and that's why there's no "18 tests" around anymore.
Andy Shevchenko June 10, 2021, 1:52 p.m. UTC | #5
On Thu, Jun 10, 2021 at 10:08:30AM -0300, André Almeida wrote:
> Às 09:39 de 10/06/21, Andy Shevchenko escreveu:
> > On Thu, Jun 10, 2021 at 2:54 PM David Gow <davidgow@google.com> wrote:
> >> On Thu, Jun 10, 2021 at 5:14 PM Andy Shevchenko
> >> <andriy.shevchenko@linux.intel.com> wrote:
> >>> On Wed, Jun 09, 2021 at 08:37:29PM -0300, André Almeida wrote:

...

> >>> It's not your fault but I think we need to defer this until KUnit gains support
> >>> of the run statistics. My guts telling me if we allow more and more conversions
> >>> like this the point will vanish and nobody will care.
> >>
> >> Did the test statistics patch we sent out before meet your expectations?
> >> https://patchwork.kernel.org/project/linux-kselftest/patch/20201211072319.533803-1-davidgow@google.com/
> > 
> > Let me look at it at some point.
> > 
> >> If so, we can tidy it up and try to push it through straight away, we
> >> were just waiting for a review from someone who wanted the feature.
> >>
> >>
> >>> I like the code, but I can give my tag after KUnit prints some kind of this:
> >>>
> >>>  * This is how the current output looks like in success:
> >>>
> >>>    test_uuid: all 18 tests passed
> >>>
> >>>  * And when it fails:
> >>>
> >>>    test_uuid: failed 18 out of 18 tests
> >>>
> >>
> >> There are some small restrictions on the exact format KUnit can use
> >> for this if we want to continue to match the (K)TAP specification
> >> which is being adopted by kselftest. The patch linked above should
> >> give something formatted like:
> >>
> >> # test_uuid: (0 / 4) tests failed (0 / 12 test parameters)
> >>
> >> Would that work for you?
> > 
> > Can you decode it for me, please?
> > 
> > (Assuming that the above question arisen, perhaps some rephrasing is
> > needed. The idea that user should have clear understanding on how many
> > test cases were run and how many of them successfully finished or
> > failed. According to this thread I have to see the cumulative number
> > of 18 (either as one number or sum over test cases or how you call
> > them, I see 4 here).
> 
> In the original code, each `if(uuid/guid_parse/equal)` was considered as
> a test, so there were 4 tests for the 3 correct inputs and 2 tests for
> the 3 wrong inputs: 4 * 3 + 2 * 3 = 18 tests.
> 
> In my patch, I've organized in a different way, with 4 test cases:
> 
> - A test case for guid_parse and guid_equal for correct inputs
> - A test case for uuid_parse and uuid_equal for correct inputs
> - A test case for guid_parse for incorrect inputs
> - A test case for uuid_parse for incorrect inputs
> 
> So now we have 4 test cases, instead of the 6 test cases in the original
> code, because I've united _parse and _equal in a single test case. Given
> that each test has 3 parameters, this is why we see 12 test parameters
> and that's why there's no "18 tests" around anymore.

I see, is it mentioned in the commit message? If no, please add this
explanation.

Let's assume 12 now is the correct number, then the output can be somehow
rephrased, but again, it's not in your patch anyway :-)
André Almeida June 10, 2021, 1:56 p.m. UTC | #6
Às 10:52 de 10/06/21, Andy Shevchenko escreveu:
> On Thu, Jun 10, 2021 at 10:08:30AM -0300, André Almeida wrote:
>> Às 09:39 de 10/06/21, Andy Shevchenko escreveu:
>>> On Thu, Jun 10, 2021 at 2:54 PM David Gow <davidgow@google.com> wrote:
>>>> On Thu, Jun 10, 2021 at 5:14 PM Andy Shevchenko
>>>> <andriy.shevchenko@linux.intel.com> wrote:
>>>>> On Wed, Jun 09, 2021 at 08:37:29PM -0300, André Almeida wrote:
> 
> ...
> 
>>>>> It's not your fault but I think we need to defer this until KUnit gains support
>>>>> of the run statistics. My guts telling me if we allow more and more conversions
>>>>> like this the point will vanish and nobody will care.
>>>>
>>>> Did the test statistics patch we sent out before meet your expectations?
>>>> https://patchwork.kernel.org/project/linux-kselftest/patch/20201211072319.533803-1-davidgow@google.com/
>>>
>>> Let me look at it at some point.
>>>
>>>> If so, we can tidy it up and try to push it through straight away, we
>>>> were just waiting for a review from someone who wanted the feature.
>>>>
>>>>
>>>>> I like the code, but I can give my tag after KUnit prints some kind of this:
>>>>>
>>>>>  * This is how the current output looks like in success:
>>>>>
>>>>>    test_uuid: all 18 tests passed
>>>>>
>>>>>  * And when it fails:
>>>>>
>>>>>    test_uuid: failed 18 out of 18 tests
>>>>>
>>>>
>>>> There are some small restrictions on the exact format KUnit can use
>>>> for this if we want to continue to match the (K)TAP specification
>>>> which is being adopted by kselftest. The patch linked above should
>>>> give something formatted like:
>>>>
>>>> # test_uuid: (0 / 4) tests failed (0 / 12 test parameters)
>>>>
>>>> Would that work for you?
>>>
>>> Can you decode it for me, please?
>>>
>>> (Assuming that the above question arisen, perhaps some rephrasing is
>>> needed. The idea that user should have clear understanding on how many
>>> test cases were run and how many of them successfully finished or
>>> failed. According to this thread I have to see the cumulative number
>>> of 18 (either as one number or sum over test cases or how you call
>>> them, I see 4 here).
>>
>> In the original code, each `if(uuid/guid_parse/equal)` was considered as
>> a test, so there were 4 tests for the 3 correct inputs and 2 tests for
>> the 3 wrong inputs: 4 * 3 + 2 * 3 = 18 tests.
>>
>> In my patch, I've organized in a different way, with 4 test cases:
>>
>> - A test case for guid_parse and guid_equal for correct inputs
>> - A test case for uuid_parse and uuid_equal for correct inputs
>> - A test case for guid_parse for incorrect inputs
>> - A test case for uuid_parse for incorrect inputs
>>
>> So now we have 4 test cases, instead of the 6 test cases in the original
>> code, because I've united _parse and _equal in a single test case. Given
>> that each test has 3 parameters, this is why we see 12 test parameters
>> and that's why there's no "18 tests" around anymore.
> 
> I see, is it mentioned in the commit message? If no, please add this
> explanation.
> 
> Let's assume 12 now is the correct number, then the output can be somehow
> rephrased, but again, it's not in your patch anyway :-)
> 

Sure! I'll add this for v3 :)