From: "José Expósito" <jose.exposito89@gmail.com>
To: Daniel Latypov <dlatypov@google.com>
Cc: jikos@kernel.org, benjamin.tissoires@redhat.com,
spbnick@gmail.com, j.witteveen@gmail.com, stefanberzl@gmail.com,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
kunit-dev@googlegroups.com
Subject: Re: [PATCH 1/7] HID: uclogic: KUnit best practices and naming conventions
Date: Mon, 11 Jul 2022 18:16:46 +0200 [thread overview]
Message-ID: <20220711161646.GA10528@elementary> (raw)
In-Reply-To: <CAGS_qxpotikOpURnnx5mVtormgEbkn7xp5Hi5FScnODa5P+_fg@mail.gmail.com>
Hi Daniel,
On Mon, Jul 11, 2022 at 07:41:53AM -0700, Daniel Latypov wrote:
> On Sun, Jul 10, 2022 at 10:51 AM José Expósito
> <jose.exposito89@gmail.com> wrote:
> >
> > The KUnit documentation [1] suggests allowing build tests as a module.
> >
> > In addition, it is recommended [2] to use snake case names for
> > kunit_suite and test cases.
>
> Test parameters don't fall under "test cases", though I see how that
> can be construed as such.
> I don't think anyone has stated any preference to standardize the naming there.
>
> We currently have parameterized tests using spaces and punctuation, e.g.
> ok 7 - binfmt_elf
> # Subtest: ext4_inode_test
> 1..1
> # Subtest: inode_test_xtimestamp_decoding
> ok 1 - 1901-12-13 Lower bound of 32bit < 0 timestamp, no extra bits
> ok 2 - 1969-12-31 Upper bound of 32bit < 0 timestamp, no extra bits
> ...
> ok 1 - mctp_test_fragment
> # Subtest: mctp_test_rx_input
> ok 1 - {1,a,8,0}
> ok 2 - {1,a,9,0}
> ok 3 - {2,a,8,0}
>
> So I think the old names were more conventional.
I changed the names to be consistent with other tests I'm working on
present in "gpu/drm/tests/drm_format_helper_test.c".
My first version there used full sentences for the test cases, but, if
I remember correctly, it was suggested to use snake case.
I don't have a strong preference about using one approach or the other.
If there is not a rule, I'd prefer to be consistent with the work I'm
doing in the DRM subsystem to avoid mixing notation or refactoring
there, but I'm open to change it.
> > Change the Kconfig entry from bool to tristate and stick to the naming
> > conventions to avoid style issues with future tests.
> >
> > Link: https://docs.kernel.org/dev-tools/kunit/style.html#test-kconfig-entries [1]
> > Link: https://www.kernel.org/doc/html/latest/dev-tools/kunit/style.html [2]
> > Signed-off-by: José Expósito <jose.exposito89@gmail.com>
>
> Everything else (renaming the suite and switching to tristate) sounds
> good to me though.
>
> Acked-by: Daniel Latypov <dlatypov@google.com>
Thanks a lot for your review! I'll wait a couple of days before
sending v2 with the Acked-by tag just in case you or somebody else
wants to add more comments.
Best wishes,
Jose
next prev parent reply other threads:[~2022-07-11 16:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-10 17:50 [PATCH 0/7] XP-PEN Deco Pro S support (for-5.20/uclogic) José Expósito
2022-07-10 17:50 ` [PATCH 1/7] HID: uclogic: KUnit best practices and naming conventions José Expósito
2022-07-11 14:41 ` Daniel Latypov
2022-07-11 16:16 ` José Expósito [this message]
2022-07-10 17:50 ` [PATCH 2/7] HID: uclogic: Refactor UGEE v2 string descriptor parsing José Expósito
2022-07-10 17:50 ` [PATCH 3/7] HID: uclogic: Refactor UGEE v2 frame initialization José Expósito
2022-07-10 17:50 ` [PATCH 4/7] HID: uclogic: Parse the UGEE v2 frame type José Expósito
2022-07-10 17:50 ` [PATCH 5/7] HID: uclogic: Add support for UGEE v2 dial frames José Expósito
2022-07-10 17:50 ` [PATCH 6/7] HID: uclogic: Add support for UGEE v2 mouse frames José Expósito
2022-07-10 17:50 ` [PATCH 7/7] HID: uclogic: Add support for XP-PEN Deco Pro S José Expósito
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220711161646.GA10528@elementary \
--to=jose.exposito89@gmail.com \
--cc=benjamin.tissoires@redhat.com \
--cc=dlatypov@google.com \
--cc=j.witteveen@gmail.com \
--cc=jikos@kernel.org \
--cc=kunit-dev@googlegroups.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=spbnick@gmail.com \
--cc=stefanberzl@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.