From 691ad12cc994219e2e981aa7013e4f50507eb839 Mon Sep 17 00:00:00 2001 From: teor Date: Tue, 13 Oct 2020 05:46:52 +1000 Subject: [PATCH] Add modules and test plans to the RFC template (#1145) --- book/src/dev/rfcs/0000-template.md | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/book/src/dev/rfcs/0000-template.md b/book/src/dev/rfcs/0000-template.md index 45f6b72c..0ac61492 100644 --- a/book/src/dev/rfcs/0000-template.md +++ b/book/src/dev/rfcs/0000-template.md @@ -42,6 +42,22 @@ This is the technical portion of the RFC. Explain the design in sufficient detai The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work. +## Module Structure + +Describe the crate and modules that will implement the feature. + +## Test Plan + +Explain how the feature will be tested, including: +* tests for consensus-critical functionality +* existing test vectors, if available +* Zcash blockchain block test vectors (specify the network upgrade, feature, or block height and network) + +The tests should cover: +* positive cases: make sure the feature accepts valid inputs +* negative cases: make sure the feature rejects invalid inputs +* edge cases: make sure that boundary conditions are correctly handled + # Drawbacks [drawbacks]: #drawbacks @@ -55,7 +71,6 @@ Why should we *not* do this? - What other designs have been considered and what is the rationale for not choosing them? - What is the impact of not doing this? - # Prior art [prior-art]: #prior-art