From: Jakub Kicinski <kuba@kernel.org>
To: Petr Machata <petrm@nvidia.com>
Cc: <davem@davemloft.net>, <netdev@vger.kernel.org>,
<edumazet@google.com>, <pabeni@redhat.com>, <shuah@kernel.org>,
<sdf@google.com>, <donald.hunter@gmail.com>,
<linux-kselftest@vger.kernel.org>
Subject: Re: [PATCH net-next 3/7] selftests: net: add scaffolding for Netlink tests in Python
Date: Tue, 2 Apr 2024 10:26:42 -0700 [thread overview]
Message-ID: <20240402102642.65681bf4@kernel.org> (raw)
In-Reply-To: <87il0zith6.fsf@nvidia.com>
On Tue, 2 Apr 2024 17:53:41 +0200 Petr Machata wrote:
> > +def ksft_ge(a, b, comment=""):
> > + global KSFT_RESULT
> > + if a < b:
> > + KSFT_RESULT = False
>
> Hmm, instead of this global KSFT_RESULT business, have you considered
> adding and raising an XsftFailEx, like for the other outcomes? We need
> to use KSFT_RESULT-like approach in bash tests, because, well, bash.
>
> Doing it all through exceptions likely requires consistent use of
> context managers for resource clean-up. But if we do, we'll get
> guaranteed cleanups as well. I see that you use __del__ and explicit
> "finally: del cfg" later on, which is exactly the sort of lifetime
> management boilerplate that context managers encapsulate.
>
> This stuff is going to get cut'n'pasted around, and I worry we'll end up
> with a mess of mutable globals and forgotten cleanups if the right
> patterns are not introduced early on.
I wanted to support the semantics which the C kselftest harness has,
by which I mean EXPECT and ASSERT. The helpers don't raise, just record
the failure and keep going. ASSERT semantics are provided by the
exceptions.
I thought it may be easier to follow and write correct code if we raise
ASSERTS explicitly in the test, rather than in the helpers. I mean - if
the programmer has to type in "raise" they are more likely to realize
they need to also add cleanup.
But TBH I'm happy to be persuaded otherwise, I couldn't find a strong
reason to do it one way or the other. I have tried to integrate with
unittest and that wasn't great (I have one huge test I need to port
back now). I don't know if pytest is better, but I decided that we
should probably roll our own. What "our own" exactly is I don't have
strong opinion.
next prev parent reply other threads:[~2024-04-02 17:26 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-02 1:05 [PATCH net-next 0/7] selftests: net: groundwork for YNL-based tests Jakub Kicinski
2024-04-02 1:05 ` [PATCH net-next 1/7] netlink: specs: define ethtool header flags Jakub Kicinski
2024-04-02 1:05 ` [PATCH net-next 2/7] tools: ynl: copy netlink error to NlError Jakub Kicinski
2024-04-02 1:05 ` [PATCH net-next 3/7] selftests: net: add scaffolding for Netlink tests in Python Jakub Kicinski
2024-04-02 15:53 ` Petr Machata
2024-04-02 17:26 ` Jakub Kicinski [this message]
2024-04-03 0:09 ` David Wei
2024-04-02 1:05 ` [PATCH net-next 4/7] selftests: nl_netdev: add a trivial Netlink netdev test Jakub Kicinski
2024-04-03 0:15 ` David Wei
2024-04-02 1:05 ` [PATCH net-next 5/7] netdevsim: report stats by default, like a real device Jakub Kicinski
2024-04-03 2:51 ` David Wei
2024-04-02 1:05 ` [PATCH net-next 6/7] selftests: drivers: add scaffolding for Netlink tests in Python Jakub Kicinski
2024-04-03 3:06 ` David Wei
2024-04-02 1:05 ` [PATCH net-next 7/7] testing: net-drv: add a driver test for stats reporting Jakub Kicinski
2024-04-02 16:37 ` Petr Machata
2024-04-02 17:31 ` Jakub Kicinski
2024-04-02 17:44 ` Jakub Kicinski
2024-04-02 22:02 ` Petr Machata
2024-04-02 22:04 ` Petr Machata
2024-04-02 23:36 ` Jakub Kicinski
2024-04-03 8:58 ` Petr Machata
2024-04-03 13:55 ` Jakub Kicinski
2024-04-03 16:52 ` Petr Machata
2024-04-03 21:48 ` Jakub Kicinski
2024-04-03 3:15 ` David Wei
2024-04-03 3:09 ` David Wei
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=20240402102642.65681bf4@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=donald.hunter@gmail.com \
--cc=edumazet@google.com \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=petrm@nvidia.com \
--cc=sdf@google.com \
--cc=shuah@kernel.org \
/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.