diff options
| author | Tom Rini <[email protected]> | 2024-08-26 18:52:18 -0600 |
|---|---|---|
| committer | Tom Rini <[email protected]> | 2024-08-26 18:52:18 -0600 |
| commit | 9735cfaf904551759597067d76e2ae2ec21d582a (patch) | |
| tree | 5578133191f3a0557deb2360e14eb367fab804b9 /doc/develop | |
| parent | 02d587a447ccae12618abbfb2b8ddd88ac3c7648 (diff) | |
| parent | 695b4645325ef40c792a6e6a3849d134fcf80ed0 (diff) | |
Merge patch series "Tidy up console recording in tests"
Simon Glass <[email protected]> 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.
Diffstat (limited to 'doc/develop')
| -rw-r--r-- | doc/develop/commands.rst | 9 | ||||
| -rw-r--r-- | doc/develop/tests_writing.rst | 18 |
2 files changed, 15 insertions, 12 deletions
diff --git a/doc/develop/commands.rst b/doc/develop/commands.rst index 5ad4e59c838..77a7a4d9c02 100644 --- a/doc/develop/commands.rst +++ b/doc/develop/commands.rst @@ -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. diff --git a/doc/develop/tests_writing.rst b/doc/develop/tests_writing.rst index 44b544fa78b..a328ebfef33 100644 --- a/doc/develop/tests_writing.rst +++ b/doc/develop/tests_writing.rst @@ -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. |
