From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [RFC PATCH 2/2] include/tst_test_macros.h: Report TINFO when TST_EXP_FD() succeeded
Date: Tue, 5 Jan 2021 16:03:53 +0100 [thread overview]
Message-ID: <X/R/2VVe1dJxGhHN@yuki.lan> (raw)
In-Reply-To: <5FF47A04.4030908@cn.fujitsu.com>
Hi!
> > What exactly is the problem of having TPASS generated for each open()
> > that produces a valid file descriptor in the open testcases?
> >
> > These macros are especially tailored to generate TPASS/TFAIL messages so
> > that the caller does not have to. So even if having two TPASS per run()
> > function in open01 was a problem, which I do not think is the case, we
> > should just use SAFE_OPEN() there instead.
> Hi Cyril,
>
> I perfer to report one TPASS message when finishing one subtest instead
> of one step.
> because of two reasons:
> a) It seems clearer for user to know how many subtests were run
> sucessfully.
This depends on a definition of subtest which, as far as I can tell, is
not that well defined.
If you want to make the output easier to read in the case of a test
function that is called more than once we should change the test library
to insert empty lines between the iterations or something along these
lines, so that the output would look like:
./open01
tst_test.c:1261: TINFO: Timeout per run is 0h 05m 00s
open01.c:48: TPASS: open() with sticky bit returned fd 3
open01.c:56: TPASS: sticky bit is set as expected
open01.c:48: TPASS: open() with sirectory bit returned fd 3
open01.c:56: TPASS: sirectory bit is set as expected
Summary:
passed 4
failed 0
broken 0
skipped 0
warnings 0
Which is way better than imposing any rules on how many TPASS/TFAIL
messages should be printed per iteration.
> b) There are too many TPASS/TFAIL messages when a testcase(e.g.
> open11) contains many subtests or multiple TST_EXP_* macros.
There are 28 testcases in open11 and we print 28 messages TPASS/TFAIL
messages, we just use different EXP macro for different testcases. I do
not think that silencing the output would make things any better.
> Could we make TST_EXP_* macros do common check and generate only TFAIL
> messages? (Make testcases report TPASS message by themself)
The whole idea of having the TST_EXP_* macros is that they replace code
that looks like:
if (condition)
tst_res(TPASS, "...");
else
tst_res(TFAIL, "...");
And that they actually unify how these messages are formatted.
If you think that there are places where we use these macros where
SAFE_MACRO() would be better we can talk about changing these.
--
Cyril Hrubis
chrubis@suse.cz
next prev parent reply other threads:[~2021-01-05 15:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-04 12:54 [LTP] [PATCH 1/2] syscalls/open01.c: Don't continue when open() failed Xiao Yang
2021-01-04 12:54 ` [LTP] [RFC PATCH 2/2] include/tst_test_macros.h: Report TINFO when TST_EXP_FD() succeeded Xiao Yang
2021-01-04 13:07 ` yangx.jy
2021-01-05 13:38 ` Cyril Hrubis
2021-01-05 13:36 ` Cyril Hrubis
2021-01-05 14:39 ` yangx.jy
2021-01-05 15:03 ` Cyril Hrubis [this message]
2021-01-10 13:04 ` [LTP] [RFC PATCH v2 1/2] include/tst_test_macros.h: Add TST_EXP_SILENT_{PASS, FD} macros Xiao Yang
2021-01-10 13:04 ` [LTP] [RFC PATCH v2 2/2] syscalls/access02.c: Take use of TST_EXP_SILENT_PASS Xiao Yang
2021-01-11 14:07 ` [LTP] [RFC PATCH v2 1/2] include/tst_test_macros.h: Add TST_EXP_SILENT_{PASS, FD} macros Cyril Hrubis
2021-01-10 13:48 ` [LTP] [RFC PATCH 2/2] include/tst_test_macros.h: Report TINFO when TST_EXP_FD() succeeded yangx.jy
2021-01-05 13:15 ` [LTP] [PATCH 1/2] syscalls/open01.c: Don't continue when open() failed Cyril Hrubis
2021-01-05 14:20 ` yangx.jy
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=X/R/2VVe1dJxGhHN@yuki.lan \
--to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox