Hi Rasmus, On Mon, 13 Jul 2026 at 01:59, Rasmus Villemoes <[email protected]> wrote: > > On Sun, Jul 12 2026, "Simon Glass" <[email protected]> wrote: > > > Hi Rasmus, > > > > On 2026-07-08T20:37:01, Rasmus Villemoes <[email protected]> wrote: > >> test: add test of 'config' command > >> > >> Add some test cases for the 'config' command, including the ability to > >> filter the output. > >> > >> Signed-off-by: Rasmus Villemoes <[email protected]> > >> > >> test/cmd/Makefile | 1 + > >> test/cmd/config.c | 28 ++++++++++++++++++++++++++++ > >> 2 files changed, 29 insertions(+) > > > > Reviewed-by: Simon Glass <[email protected]> > > > >> diff --git a/test/cmd/config.c b/test/cmd/config.c > >> @@ -0,0 +1,28 @@ > >> + ut_assertok(run_command('config', 0)); > >> + ut_assert_skip_to_line("# Automatically generated file; DO NOT > >> EDIT."); > >> + ut_assert_skip_to_linen("# Compiler:"); > >> + ut_assert_skip_to_line('CONFIG_CMD_CONFIG=y'); > >> + > >> + console_record_reset_enable(); > > > > Just to check, is there a reason the first block doesn't finish with > > ut_assert_console_end() before the reset? The other invocations round > > out with it, and it would be nice to verify we consumed to a known > > point rather than discarding whatever was left. > > Yes. When printing the whole .config, I know that there'll be the > commented out lines I check for at the top, and obviously also the > CMD_CONFIG option itself must be enabled. But I don't know anything else > about what might be in the .config, and in particular, there's no way to > know what the last line will look like (the .config file does not have a > "# end of .config" footer or similar). So I can neither skip to or > assert existence of other lines after the CONFIG_CMD_CONFIG=y check. I > don't think there's anything else to do. > > When invoked with a filter, I do know exactly what line(s) to expect, in > in those cases it is also more important to assert that there are no > unexpected lines.
Yes fair enough and I've hit this sort of thing too. When something fails, ut_assert_skip_to_line() is quite annoying - you don't really know where to look in the output. I have long wanted a better mechanism but have not thought of one. Regards, Simon
