quickjs-tart

quickjs-based runtime for wallet-core logic
Log | Files | Refs | README | LICENSE

test-framework.md (3963B)


      1 # Mbed TLS test framework
      2 
      3 This document is an overview of the Mbed TLS test framework and test tools.
      4 
      5 This document is incomplete. You can help by expanding it.
      6 
      7 ## Unit tests
      8 
      9 See <https://mbed-tls.readthedocs.io/en/latest/kb/development/test_suites>
     10 
     11 ### Unit test descriptions
     12 
     13 Each test case has a description which succinctly describes for a human audience what the test does. The first non-comment line of each paragraph in a `.data` file is the test description. The following rules and guidelines apply:
     14 
     15 * Test descriptions may not contain semicolons, line breaks and other control characters, or non-ASCII characters. <br>
     16   Rationale: keep the tools that process test descriptions (`generate_test_code.py`, [outcome file](#outcome-file) tools) simple.
     17 * Test descriptions must be unique within a `.data` file. If you can't think of a better description, the convention is to append `#1`, `#2`, etc. <br>
     18   Rationale: make it easy to relate a failure log to the test data. Avoid confusion between cases in the [outcome file](#outcome-file).
     19 * Test descriptions should be a maximum of **66 characters**. <br>
     20   Rationale: 66 characters is what our various tools assume (leaving room for 14 more characters on an 80-column line). Longer descriptions may be truncated or may break a visual alignment. <br>
     21   We have a lot of test cases with longer descriptions, but they should be avoided. At least please make sure that the first 66 characters describe the test uniquely.
     22 * Make the description descriptive. “foo: x=2, y=4” is more descriptive than “foo #2”. “foo: 0<x<y, both even” is even better if these inequalities and parities are why this particular test data was chosen.
     23 * Avoid changing the description of an existing test case without a good reason. This breaks the tracking of failures across CI runs, since this tracking is based on the descriptions.
     24 
     25 `framework/scripts/check_test_cases.py` enforces some rules and warns if some guidelines are violated.
     26 
     27 ## TLS tests
     28 
     29 ### SSL extension tests
     30 
     31 #### SSL test case descriptions
     32 
     33 Each test case in `ssl-opt.sh` has a description which succinctly describes for a human audience what the test does. The test description is the first parameter to `run_test`.
     34 
     35 The same rules and guidelines apply as for [unit test descriptions](#unit-test-descriptions). In addition, the description must be written on the same line as `run_test`, in double quotes, for the sake of `check_test_cases.py`.
     36 
     37 ### SSL cipher suite tests
     38 
     39 Each test case in `compat.sh` has a description which succinctly describes for a human audience what the test does. The test description is `$TITLE` defined in `run_client`.
     40 
     41 The same rules and guidelines apply as for [unit test descriptions](#unit-test-descriptions). In addition, failure cause in `compat.sh` is not classified as `ssl-opt.sh`, so the information of failed log files are followed as prompt.
     42 
     43 ## Running tests
     44 
     45 ### Outcome file
     46 
     47 #### Generating an outcome file
     48 
     49 Unit tests, `ssl-opt.sh` and `compat.sh` record the outcome of each test case in a **test outcome file**. This feature is enabled if the environment variable `MBEDTLS_TEST_OUTCOME_FILE` is set. Set it to the path of the desired file.
     50 
     51 If you run `all.sh --outcome-file test-outcome.csv`, this collects the outcome of all the test cases in `test-outcome.csv`.
     52 
     53 #### Outcome file format
     54 
     55 The outcome file is in a CSV format using `;` (semicolon) as the delimiter and no quoting. This means that fields may not contain newlines or semicolons. There is no title line.
     56 
     57 The outcome file has 6 fields:
     58 
     59 * **Platform**: a description of the platform, e.g. `Linux-x86_64` or `Linux-x86_64-gcc7-msan`.
     60 * **Configuration**: a unique description of the configuration (`mbedtls_config.h`).
     61 * **Test suite**: `test_suite_xxx`, `ssl-opt` or `compat`.
     62 * **Test case**: the description of the test case.
     63 * **Result**: one of `PASS`, `SKIP` or `FAIL`.
     64 * **Cause**: more information explaining the result.