Unit test extension for prodtest CLI

[kopecdav]

This PR introduce an extension to prodtest CLI which allows to register unit tests.

Idea is, that every driver or firmware component may have a several low level unit tests exercising fundamental features, This should be giving user (or maybe in future to automated tester) the quick overview of the FW and HW integrity.

Unit tests ~ compared to prodtest commands ~ are not callable commands from prodtest CLI, but the prodtest CLI introduce new command unit-test-run, which run all registered unit tests and return trace of results followed with "OK" if all tests passed.

Example:

# Running all unit tests...
# ut-pmic-battery: PASSED
# ut-pmic-init-deinit: PASSED
OK

# Running all unit tests...
# ut-pmic-battery: FAILED
# ut-pmic-init-deinit: PASSED
ERROR

Unit test design

unit test of specific driver or FW component should be part of dedicated cmd/prodtest_x.c source file. Every unit test is a function with no arguments which returns ut_status_t (UT_PASSED or UT_FAILED).

static ut_status_t ut_<driver>_x(); 

Unit tests should be designed by the driver/component owner and it should pay attention to be:

• standalone - should do full initialization and deinitialization, not affect other unit tests.
• simple - should cover mainly some fundamental features. In best case you should recognize whats wrong just by seeing the test to fail without further debug.

unit tests could cover either FW integrity of specific driver/lib ~ such as init/deinit test, test if not allowed arguments are correctly recognized, etc. or HW integrity by testing communication peripherals of subordinate devices and other physical connections.

minimally, every driver should have an init/deinit test.

Example:

// ut-pmic-battery
// This unit test verifies the battery connection to NPM1300 PMIC.
// Firstly it initilize the PMIC driver and request the measurement
// report. From the measurement report it checks, if the battery voltage and
// NTC temperature are within the expeted range. At last, it checks if NTC
// temperature measurement is not too far away from the die temperarture.
static ut_status_t ut_pmic_battery() {
  ut_status_t ut_result = UT_PASSED;
  npm1300_report_t report;

  if (npm1300_init() == false) {
    ut_result = UT_FAILED;
  } else {
    // Request mesaurement report from PMIC
    if (npm1300_measure_sync(&report) == false) {
      ut_result = UT_FAILED;
    } else {
      // Battery voltage outside given range
      if (report.vbat < 3.0 || report.vbat > 3.8) {
        ut_result = UT_FAILED;
      }

      // Battery NTC outside given range
      if (report.ntc_temp < -40.0 || report.ntc_temp > 50.0) {
        ut_result = UT_FAILED;
      }

      // Battery NTC too far from die temp
      if (abs(report.ntc_temp - report.die_temp) > 10.0) {
        ut_result = UT_FAILED;
      }
    }
  }

  npm1300_deinit();
  return ut_result;
}

unit test registration

to register the unit test we use REGISTER_UNIT_TEST macro (similar to PRODTEST_CLI_CMD, but args are omitted). Same as the CLI commands, unit tests are placed in the dedicated part of memory defined in linker.

REGISTER_UNIT_TEST(
  .name = "ut-pmic-battery",
  .func = ut_pmic_battery,
  .info = "Test PMIC battery connection",
)

[github-actions]

core UI changes	device test	click test	persistence test
T2T1 Model T	test(screens) main(screens)	test(screens) main(screens)	test(screens) main(screens)
T3B1 Safe 3	test(screens) main(screens)	test(screens) main(screens)	test(screens) main(screens)
T3T1 Safe 5	test(screens) main(screens)	test(screens) main(screens)	test(screens) main(screens)
All	main(screens)

[cepetr]

This looks like this #include in unnecessary now and can be deleted.