CHROMIUM: test_util_common: Make TEST_FILE_CONTAINS() intuitive
TEST_FILE_CONTAINS() is documented to look for "subsequent" lines in the
file, but this is clearly not very intuitive, as there are several tests
that are looking for un-ordered sets of content and yet are calling
TEST_FILE_CONTAINS() several times in a row on the same file. In fact,
the only instance that seems to care about file positioning is at
init/tests/test_event.c:1166, where we see something like:
rewind (output);
...
TEST_FILE_CONTAINS (output, "some error string");
TEST_FILE_END (output);
This doesn't really conflict with the intuitive definition -- that
TEST_FILE_CONTAINS will find a line anywhere in the file, regardless of
last seek position.
So, drop the "subsequent" language, and rewind the file before scanning.
This resolves some test errors like the following:
...ensure '--user --no-inherit-env' provides expected job environment
BAD: wrong content in file 0x5c42cccf2290 (fi), 'TERM=*' not found
at tests/test_initctl.c:18185 (test_no_inherit_job_env).
FAIL test_initctl (exit status: 134)
In these cases, it seems like the 'env' command is producing different
output ordering than the test authors first encoded in the test. I'm not
sure if this was reliable at some point (e.g., due to shell
implementation details?), or if it was always inconsistent, but by my
understanding, this is not defined/specified behavior.
BUG=b:232122437
TEST=cros_run_unit_tests
Change-Id: If4d6329e0f1cb84c4b46f266d1f1961b99666aef
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/upstart/+/5435498
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Commit-Queue: Brian Norris <briannorris@chromium.org>
1 file changed
