[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGS_qxry-php+k7QvgsBVxRna=896O8AdLph+Je5GjNXa2q9HA@mail.gmail.com>
Date: Thu, 15 Dec 2022 11:01:02 -0800
From: Daniel Latypov <dlatypov@...gle.com>
To: Bagas Sanjaya <bagasdotme@...il.com>
Cc: David Gow <davidgow@...gle.com>,
Brendan Higgins <brendan.higgins@...ux.dev>,
Shuah Khan <skhan@...uxfoundation.org>,
Kees Cook <keescook@...omium.org>,
Sadiya Kazi <sadiyakazi@...gle.com>,
Steven Rostedt <rostedt@...dmis.org>,
Joe Fradley <joefradley@...gle.com>,
Steve Muckle <smuckle@...gle.com>,
Jonathan Corbet <corbet@....net>,
linux-kselftest@...r.kernel.org, kunit-dev@...glegroups.com,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] Documentation: Add Function Redirection API docs
On Thu, Dec 8, 2022 at 2:07 AM Bagas Sanjaya <bagasdotme@...il.com> wrote:
>
> On Thu, Dec 08, 2022 at 02:18:41PM +0800, David Gow wrote:
> > From: Sadiya Kazi <sadiyakazi@...gle.com>
> >
> > Added a new page (functionredirection.rst) that describes the Function
> > Redirection (static stubbing) API. This page will be expanded if we add,
> > for example, ftrace-based stubbing.
>
> s/Added/Add
>
> > diff --git a/Documentation/dev-tools/kunit/api/functionredirection.rst b/Documentation/dev-tools/kunit/api/functionredirection.rst
> > new file mode 100644
> > index 000000000000..fc7644dfea65
> > --- /dev/null
> > +++ b/Documentation/dev-tools/kunit/api/functionredirection.rst
> > @@ -0,0 +1,162 @@
> > +.. SPDX-License-Identifier: GPL-2.0
> > +
> > +========================
> > +Function Redirection API
> > +========================
> > +
> > +Overview
> > +========
> > +
> > +When writing unit tests, it's important to be able to isolate the code being
> > +tested from other parts of the kernel. This ensures the reliability of the test
> > +(it won't be affected by external factors), reduces dependencies on specific
> > +hardware or config options (making the test easier to run), and protects the
> > +stability of the rest of the system (making it less likely for test-specific
> > +state to interfere with the rest of the system).
>
> Test reliability is test independence, right?
Just my 2c, but I'd disagree.
E.g. a test can depend on CONFIG_FOO being built-in, even though it
doesn't really need it.
Having an extra kconfig dependency doesn't necessarily make the test
less reliable.
You could define "test independence" wrt shared runtime state (e.g.
multiple tests touching the same global var), but this text
specifically says "hardware or config options."
Daniel
Powered by blists - more mailing lists