Re: [PATCH v2 00/12] test: Add support for passing arguments to C unit tests

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 2514 bytes --]

On Sun, Apr 12, 2026 at 05:19:37AM -0600, Simon Glass wrote:
> Some tests have two parts: a Python test which handles setup, such as
> creating filesystem images or configuring the environment, and a C
> test which does the bulk of the work including assertions. At present
> there is no way to pass information between these two parts, so
> things like paths and device names must be hard-coded in the C test.
> 
> This tends to make people write tests in Python, but this is not ideal
> for several reasons:

You still need to work on explaining your changes in a positive manner.

> - Python lacks access to things like return codes and has to scan the
>   console output to figure out what happened

Pro: Python exercises things the way users exercise them and so exposes
deficiencies in our user interface as well, when applicable.

> - Python lacks access to internal state, so it cannot directly check
>   the result of an operation

It's unclear when that is, or is not a problem and when tests that do
check intermediate state are providing value.

> - Python is ~100x slower due to console interaction, etc.

Again, maybe you should go back to your suggestion of several years ago
to see about addressing that, as the tests themselves are not slow, it's
the pipe? Our brave new AI powered world runs on Python handing stuff
off and getting it back super quickly.

> - C tests can be stepped through in gdb, which is much harder with
>   Python driving the console
> - C tests can exercise internal APIs directly (e.g. fs_read(),
>   fs_size()) rather than going through the command layer, so they
>   test more precisely what they intend to

All things that may or may not be problems for other people, or are
intentional choices as they again test the system the way it's used.
Using gdb attached to u-boot in the other terminal where you're running
breaking things sounds like a reasonable debug path to me. And having
unit tests calling in to functions is why today we have a lot of things
not marked as "static" and so not being optimized as well as they could
by the compiler, which is its own set of trade-offs and not an automatic
good thing and design win.

[snip]
>  16 files changed, 1437 insertions(+), 279 deletions(-)

All of which is to say, you need to explain yourself in a positive, not
negative or oppositional way. Otherwise this reads like "I don't like
what we do now, here's a bunch of change to what I like instead".

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]