From: Petr Vorel <pvorel@suse.cz>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] doc: Add basic shell test description
Date: Wed, 12 Nov 2025 15:06:08 +0100 [thread overview]
Message-ID: <20251112140608.GA141617@pevik> (raw)
In-Reply-To: <20251110102407.15308-1-chrubis@suse.cz>
Hi Cyril,
Thanks for this!
Reviewed-by: Petr Vorel <pvorel@suse.cz>
Few notes below.
> diff --git a/doc/developers/api_shell_tests.rst b/doc/developers/api_shell_tests.rst
> index b6e8560d9..bad9f1f4b 100644
> --- a/doc/developers/api_shell_tests.rst
> +++ b/doc/developers/api_shell_tests.rst
> @@ -2,3 +2,94 @@
> LTP shell API
> =============
> +
> +Shell API overview
> +------------------
> +
> +First lines of the shell test should be a shebang, a license, and copyrights.
> +
> +.. code-block:: shell
> +
> + #!/bin/sh
> + # SPDX-License-Identifier: GPL-2.0-or-later
> + # Copyright 2099 Foo Bar <foo.bar@email.com>
> +
> +A documentation comment block formatted in ReStructuredText should follow right
> +after these lines. This comment is parsed and exported into the LTP
> +documentation at https://linux-test-project.readthedocs.io/en/latest/users/test_catalog.html
+1. Great, I did not realize it's ok to use at least #doc part for normal shell
tests (i.e. these without shell loader).
> +
> +.. code-block:: shell
> +
> + # ---
> + # doc
> + # Test for a foo bar.
> + #
> + # This test is testing foo by checking that bar is doing xyz.
> + # ---
> +
I would frankly link the old API doc (and link :master:`testcases/lib/tst_test.sh`)...
https://github.com/linux-test-project/ltp/blob/master/doc/old/Shell-Test-API.asciidoc
> +The shell loader test library uses the C test library internally by parsing a
> +special JSON formatted comment and initializing it accordingly. The JSON format
> +is nearly 1:1 serialization of the C tst_test structure into a JSON. The
> +environment must be always preset even when it's empty.
And here would have subtitle "shell loader test library". Why? It'd be good to
admit we have plain shell (which uses tst_test.sh) and shell loader. Of course,
shell loader could be a mentioned first, then old API:
Shell Loader Test Library
-------------------------
The shell loader test library uses the C test library internally by parsing a
special JSON formatted comment and initializing it accordingly. The JSON format
is nearly 1:1 serialization of the C tst_test structure into a JSON. The
environment must be always preset even when it's empty.
Legacy Shell Test Library
-------------------------
See :master:`testcases/lib/tst_test.sh`) and
https://github.com/linux-test-project/ltp/blob/master/doc/old/Shell-Test-API.asciidoc
.. warning::
:master:`testcases/lib/tst_test.sh` is deprecated, please use Shell Loader
Test Library.
> +
> +.. code-block:: shell
> +
> + # ---
> + # env
> + # {
> + # "needs_root": true,
> + # "needs_tmpdir": true,
> + # "needs_kconfigs": ["CONFIG_NUMA=y"],
> + # "tags": {
> + # ["linux-git", "432fd03240fa"]
> + # }
> + # }
> +
> +After the documentation and environment has been laid out we finally import the
> +`tst_loader.sh`. This will, among other things, start the `tst_run_shell`
Could we please instead `` use :master:`relative path` format which convert
source to the link:
:master:`testcases/lib/tst_loader.sh`. This will, among other things, start the
:master:`testcases/lib/tst_run_shell.c` ...
This will help people to look at the sources which is always helpful.
> +binary, that will parse the shell test environment comment and initialize the C
> +test library accordingly.
> +
> +.. code-block:: shell
> +
> + . tst_loader.sh
> +
> +At this point everything has been set up and we can finally write the test
> +function. The test results are reported by the usual functions `tst_res` and
> +`tst_brk`. As in the C API these functions store results into a piece of shared
> +memory as soon as they return so there is no need to propagate results event
> +from child processes.
> +
> +.. code-block:: shell
> +
> + tst_test()
> + {
> + tst_res TPASS "Bar enabled Foo"
> + }
> +
> +In order for the test to be actually executed the very last line of the script
> +must source the `tst_run.sh` script.
> +
> +.. code-block:: shell
> +
> + . tst_run.sh
> +
> +In order to run a test from a LTP tree a few directories has to be added to the
> +`$PATH`. Note that the number of `../` may depend on the depth of the current
> +directory relative to the LTP root.
> +
> +.. code-block:: shell
> +
> + $ PATH=$PATH:$PWD:$PWD/../../lib/ ./foo01.sh
> +
> +
> +Test setup and cleanup
> +----------------------
> +
> +The test setup and cleanup functions are optioinal and passed via variables.
> +Similarily to the C API the setup is executed exactly once at the start of the
> +test and the test cleanup is executed at the test end or when test was
> +interrupted by `tst_brk`.
> +
> +.. literalinclude:: ../../testcases/lib/tests/shell_loader_setup_cleanup.sh
> + :language: shell
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2025-11-12 14:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-10 10:24 [LTP] [PATCH] doc: Add basic shell test description Cyril Hrubis
2025-11-12 12:50 ` Avinesh Kumar
2025-11-12 14:06 ` Petr Vorel [this message]
2025-11-12 15:18 ` Cyril Hrubis
2025-11-12 19:00 ` Petr Vorel
2025-11-13 10:21 ` Cyril Hrubis
2025-11-14 9:22 ` Petr Vorel
2025-11-12 14:19 ` Petr Vorel
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=20251112140608.GA141617@pevik \
--to=pvorel@suse.cz \
--cc=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
/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.