From 8b193c10cac024b7e33320818cbb3b156efb8d1e Mon Sep 17 00:00:00 2001 From: Gilles Peskine Date: Thu, 5 Sep 2019 17:58:13 +0200 Subject: [PATCH] Check inputs too --- docs/architecture/testing/driver-interface-test-strategy.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/architecture/testing/driver-interface-test-strategy.md b/docs/architecture/testing/driver-interface-test-strategy.md index 2f31c0010..d6769da0b 100644 --- a/docs/architecture/testing/driver-interface-test-strategy.md +++ b/docs/architecture/testing/driver-interface-test-strategy.md @@ -41,6 +41,7 @@ For each API function that can lead to a driver call (more precisely, for each d * Wherever the specification guarantees parameters that satisfy certain preconditions, check these preconditions whenever practical. * If the API function can take parameters that are invalid and must not reach the driver, call the API function with such parameters and verify that the driver method is not called. +* Check that the expected inputs reach the driver. This may be implicit in a test that checks the outputs if the only realistic way to obtain the correct outputs is to start from the expected inputs (as is often the case for cryptographic material, but not for metadata). #### SE driver outputs