mirror of
https://source.denx.de/u-boot/u-boot.git
synced 2026-06-13 15:03:58 +03:00
Merge patch series "Tidy up console recording in tests"
Simon Glass <sjg@chromium.org> says: This series started as a small fix for checking for an empty line, but in the process several other problems were found and fixed: - fix tests which use console recording but don't set the flag - drop unnecessary resetting of the console in tests - drop unnecessary blank line before MMC output - update the docs a little - fix buildman test failure on newer Pythons - a few other minor things This series also renames the confusing flag names, so that they are easier to remember - just a UTF_ (unit-test flags) prefix.
This commit is contained in:
@@ -197,7 +197,6 @@ Here is an example:
|
||||
|
||||
ctx.current = buf;
|
||||
ut_assertok(acpi_fill_ssdt(&ctx));
|
||||
console_record_reset();
|
||||
run_command("acpi items", 0);
|
||||
ut_assert_nextline("dev 'acpi-test', type 1, size 2");
|
||||
ut_assert_nextline("dev 'acpi-test2', type 1, size 2");
|
||||
@@ -205,13 +204,11 @@ Here is an example:
|
||||
|
||||
ctx.current = buf;
|
||||
ut_assertok(acpi_inject_dsdt(&ctx));
|
||||
console_record_reset();
|
||||
run_command("acpi items", 0);
|
||||
ut_assert_nextline("dev 'acpi-test', type 2, size 2");
|
||||
ut_assert_nextline("dev 'acpi-test2', type 2, size 2");
|
||||
ut_assert_console_end();
|
||||
|
||||
console_record_reset();
|
||||
run_command("acpi items -d", 0);
|
||||
ut_assert_nextline("dev 'acpi-test', type 2, size 2");
|
||||
ut_assert_nextlines_are_dump(2);
|
||||
@@ -223,4 +220,8 @@ Here is an example:
|
||||
|
||||
return 0;
|
||||
}
|
||||
DM_TEST(dm_test_acpi_cmd_items, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
|
||||
DM_TEST(dm_test_acpi_cmd_items, UTF_SCAN_PDATA | UTF_SCAN_FDT | UTF_CONSOLE);
|
||||
|
||||
Note that it is not necessary to call console_record_reset() unless you are
|
||||
trying to drop some unchecked output. Consider using ut_check_skip_to_line()
|
||||
instead.
|
||||
|
||||
@@ -81,7 +81,7 @@ The best of both worlds is sometimes to have a Python test set things up and
|
||||
perform some operations, with a 'checker' C unit test doing the checks
|
||||
afterwards. This can be achieved with these steps:
|
||||
|
||||
- Add the `UT_TESTF_MANUAL` flag to the checker test so that the `ut` command
|
||||
- Add the `UTF_MANUAL` flag to the checker test so that the `ut` command
|
||||
does not run it by default
|
||||
- Add a `_norun` suffix to the name so that pytest knows to skip it too
|
||||
|
||||
@@ -95,7 +95,7 @@ test to run it, e.g.::
|
||||
# Run the checker to make sure that everything worked
|
||||
ut -f bootstd vbe_test_fixup_norun
|
||||
|
||||
Note that apart from the `UT_TESTF_MANUAL` flag, the code in a 'manual' C test
|
||||
Note that apart from the `UTF_MANUAL` flag, the code in a 'manual' C test
|
||||
is just like any other C test. It still uses ut_assert...() and other such
|
||||
constructs, in this case to check that the expected things happened in the
|
||||
Python test.
|
||||
@@ -151,7 +151,6 @@ There is no exactly equivalent C test, but here is a similar one that tests 'ms'
|
||||
buf[0x31] = 0x12;
|
||||
buf[0xff] = 0x12;
|
||||
buf[0x100] = 0x12;
|
||||
ut_assertok(console_record_reset_enable());
|
||||
run_command("ms.b 1 ff 12", 0);
|
||||
ut_assert_nextline("00000030: 00 12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................");
|
||||
ut_assert_nextline("--");
|
||||
@@ -167,7 +166,7 @@ There is no exactly equivalent C test, but here is a similar one that tests 'ms'
|
||||
|
||||
return 0;
|
||||
}
|
||||
MEM_TEST(mem_test_ms_b, UT_TESTF_CONSOLE_REC);
|
||||
MEM_TEST(mem_test_ms_b, UTF_CONSOLE);
|
||||
|
||||
This runs the command directly in U-Boot, then checks the console output, also
|
||||
directly in U-Boot. If run by itself this takes 100ms. For 1000 runs it takes
|
||||
@@ -226,14 +225,17 @@ Declare the test with::
|
||||
|
||||
return 0;
|
||||
}
|
||||
DM_TEST(dm_test_uclassname_what, UT_TESTF_SCAN_FDT);
|
||||
DM_TEST(dm_test_uclassname_what, UTF_SCAN_FDT);
|
||||
|
||||
Note that the convention is to NOT add a blank line before the macro, so that
|
||||
the function it relates to is more obvious.
|
||||
|
||||
Replace 'uclassname' with the name of your uclass, if applicable. Replace 'what'
|
||||
with what you are testing.
|
||||
|
||||
The flags for DM_TEST() are defined in test/test.h and you typically want
|
||||
UT_TESTF_SCAN_FDT so that the devicetree is scanned and all devices are bound
|
||||
and ready for use. The DM_TEST macro adds UT_TESTF_DM automatically so that
|
||||
UTF_SCAN_FDT so that the devicetree is scanned and all devices are bound
|
||||
and ready for use. The DM_TEST macro adds UTF_DM automatically so that
|
||||
the test runner knows it is a driver model test.
|
||||
|
||||
Driver model tests are special in that the entire driver model state is
|
||||
@@ -263,7 +265,7 @@ with the suite. For example, to add a new mem_search test::
|
||||
|
||||
return 0;
|
||||
}
|
||||
MEM_TEST(mem_test_ms_new_thing, UT_TESTF_CONSOLE_REC);
|
||||
MEM_TEST(mem_test_ms_new_thing, UTF_CONSOLE);
|
||||
|
||||
Note that the MEM_TEST() macros is defined at the top of the file.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user