Add modules and test plans to the RFC template (#1145)
This commit is contained in:
parent
2d0d8eb2fd
commit
691ad12cc9
|
@ -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.
|
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]: #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 other designs have been considered and what is the rationale for not choosing them?
|
||||||
- What is the impact of not doing this?
|
- What is the impact of not doing this?
|
||||||
|
|
||||||
|
|
||||||
# Prior art
|
# Prior art
|
||||||
[prior-art]: #prior-art
|
[prior-art]: #prior-art
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue