This exercises a few success and failure modes of the log filter-*
commands. log filter-list is not tested because it's purely informational.
I don't think there's a good way to test it except by testing if the output
of the command exactly matches a sample run.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When rebasing this series I had to renumber all my log tests because
someone made another log test in the meantime. This involved updaing a
number in several places (C and python), and it wasn't checked by the
compiler. So I though "how hard could it be to just rewrite in C?" And
though it wasn't hard, it *was* tedious. Tests are numbered the same as
before to allow for easier review.
A note that if a test fails, everything after it will probably also fail.
This is because that test won't clean up its filters. There's no easy way
to do the cleanup, except perhaps removing all filters in a wrapper
function.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
If CONFIG_LOG=n, we still expect output for log_err(), log_warning(),
log_notice(), log_info() and in case of DEBUG=1 also for log_debug().
Provide unit tests verifying this.
The tests depend on:
CONFIG_CONSOLE_RECORD=y
CONFIG_LOG=n
CONFIG_UT_LOG=y
It may be necessary to increase the value of CONFIG_SYS_MALLOC_F_LEN to
accommodate CONFIG_CONSOLE_RECORD=y.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
