Lines Matching refs:test
5 In Mbed TLS, we use black-box testing as much as possible: test the documented behavior of the prod…
9 This is a test strategy document, not a test plan. A description of exactly what is tested is out o…
30 Do not add test-specific interfaces if there's a practical way of doing it another way. All public …
34 In unit tests and in test programs, it's ok to include internal header files from `library/`. Do no…
36 …ch functions in `library/*.h` and include the corresponding header in the test code. If the functi…
38 If test code or test data depends on internal details of the library and not just on its documented…
41 > /* This test file is specific to the ITS implementation in PSA Crypto
48 > # This test assumes that PSA_MAX_KEY_BITS (currently 65536-8 bits = 8191 bytes
55 If the most practical way to test something is to add code to the product that is only useful for t…
57 * **Only use test-specific code when necessary.** Anything that can be tested through the documente…
58 …d by `#if defined(MBEDTLS_TEST_HOOKS)`**. Do not create fine-grained guards for test-specific code.
60 …ctures, but if so, make it very clear that these fields have no impact on non-test-specific fields.
65 …how to replace a library function `mbedtls_foo()` by alternative code for test purposes. That is, …
67 …cro can be replaced at compile time to support alternative platforms, the test code should be comp…
69 …identally skipping side effects in its parameters), to provide a hook for test code; such function…
73 In unit test code that needs to modify the internal behavior:
75 * The test function (or the whole test file) must depend on `MBEDTLS_TEST_HOOKS`.
76 * At the beginning of the test function, set the global function pointers to the desired value.
77 * In the test function's cleanup code, restore the global function pointers to their default value.
85 * Coverage: we need to test behaviors which are not easy to trigger by using the API or which canno…
86 * Correctness: we want to test the actual product, not a modified version, since conclusions drawn …
87 * Effacement: the product should not include features that are solely present for test purposes, si…
97 Resource allocation can fail, but rarely does so in a typical test environment. How does the produc…
111 We also need to test resilience: if the system is reset during an operation, does it restart in a c…
129 * Inject faults and test corruption checks inside the product.
143 …test in the public interface. Then the tests can be truly black-box. The limitation of this approa…
156 | | ! Public interfaces must remain for backward compatibility even if the test arc…
160 …test in undocumented interfaces. Undocumented interfaces are described in public headers for the s…
174 … in the public interfaces. This is nice when it works, because it lets us test the unchanged produ…
180 …y portable since it only relies on C interfaces. A limitation is that the test-only interfaces mus…
187 | Effacement | ++ Fine as long as the internal interfaces aren't added solely for test purposes |
194 If we guarantee certain properties through static analysis, we don't need to test them. This puts s…
196 …n the specification (but we can gain this confidence by evaluating the specification on test data).
214 | Correctness | ! Difficult to ensure that what we test is what we run |
224 …Either we're testing or we're not. Fine-grained options for testing would require more test builds…
226 …When building in test mode, the code should have exactly the same behavior. Changing the behavior …
228 …We should not have test-specific conditional compilation littered through the code, as that makes …
244 | | + Many properties come for free, but some require effort (e.g. the test code it…
248 If we want to do something in a test that the product isn't capable of doing, we can use a debugger…
254 …ts is hard. We need to have confidence that we're testing what we mean to test, even in the face o…
276 Goal: test that `mbedtls_platform_zeroize` does wipe the memory buffer.
284 Goal: test the absence of memory leaks.
288 …test jobs with a memory leak detector, each test function or test program must clean up after itse…
292 Solution: TODO. We don't test this at all at this point.
296 Goal: test the absence of resource leaks in the PSA key store code, in particular that `psa_close_k…
298 …`PSA_DONE()` instead of `mbedtls_psa_crypto_free()`. `PSA_DONE` fails the test if the key store in…
308 Goal: test that no stray files are left over in the key store after a test that succeeded.
310 Solution: TODO. Currently the various test suites do it differently.
314 Goal: ensure that no stray files are left over in the key store even if a test has failed (as that …
316 Solution: TODO. Currently the various test suites do it differently.
320 Goal: test the resilience of PSA storage against power failures.
324 See the [secure element driver interface test strategy](driver-interface-test-strategy.html) for mo…
328 Goal: test the robustness against corrupted storage.
334 Goal: test the robustness against read errors.
340 Goal: test the robustness against write errors (`STORAGE_FAILURE` or `INSUFFICIENT_STORAGE`).
346 Goal: test that the storage format does not change between versions (or if it does, an upgrade path…
356 Goal: test the failure of `psa_crypto_init`.