100% test coverage in consensus package

[lukechampine]

Even 100% coverage doesn't guarantee your code is bug-free, but it's certainly a great first step. Let's try to reach 100% coverage in consensus, testing every single edge case. :)

Any increase in test coverage, even 1%, qualifies for our Hacktoberfest event, so don't be shy!

[rajkumarGosavi]

Hi @lukechampine i have raised a minor PR to increase coverage for update.go and validate.go, please review.

[lukechampine]

Here's a listing of the remaining uncovered code, with my suggestions on how to write a test for them:

• storageProofRoot
  • this is used for v2 storage proofs, so validate a transaction that resolves a v2 contract with a storage proof.
• (acc *ElementAccumulator) UnmarshalJSON
  • just need to add some test cases with invalid json
• (acc *ElementAccumulator) containsChainIndex
  • this would also be covered by a v2 storage proof
• (acc *ElementAccumulator) containsResolvedV2FileContractElement
  • ditto
• (eau *elementApplyUpdate) updateElementProof
  • needs a test case for updating an ephemeral element
• (eru *elementRevertUpdate) updateElementProof
  • apply a block, update a proof, revert the block, update the proof again, then check that the proof matches the original
• (s State) MaxFutureTimestamp
  • no real behavior to test here, so just write a trivial comparison
• (s State) BlockReward
  • need a test case with network parameters where InitialCoinbase != MinimumCoinbase
• (s State) FoundationSubsidy
  • need a test case that fast-forwards to a regular subsidy block
• (s State) FileContractTax
  • need a test case for a v1 contract below the tax hardfork height
• (s State) StorageProofLeafIndex
  • this will be covered by a v2 contract test
• (s State) StorageProofLeafHash
  • ditto
• (s State) replayPrefix
  • a good test would be to calculate WholeSigHash at various heights and check that they do/do not match
• (ms *MidState) siacoinElement (and similar)
  • these need tests cases involving ephemeral elements, i.e. a parent->child chain where the child spends an output created by the parent
• (ts V1TransactionSupplement) storageProofWindowID
  • should be covered by a v1 contract storage proof?
• updateOakTime
  • needs a test case at a specific height
• updateOakTarget
  • needs a test case at a specific height
• adjustTarget
  • the target isn't adjusted until block 1000, so we need a test that fast-forwards to that height
• (ms *MidState) resolveFileContractElement
  • another v1 contract storage proof test
• (ms *MidState) resolveV2FileContractElement
  • same but for v2
• (ms *MidState) ApplyTransaction
  • more storage proof stuff, also foundation updates
• (ms *MidState) ApplyV2Transaction
  • need to test all v2 contract resolution types; also attestations and foundation updates
• (ms *MidState) ApplyBlock
  • need to test missed storage proofs
• (ru RevertUpdate) UpdateElementProof
  • this would be covered by the revert test described above
• (ru RevertUpdate) ForEachFileContractElement
  • revert a block with a contract in it and see that it's listed
• (ru RevertUpdate) ForEachV2FileContractElement
  • ditto for v2
• validateHeader
  • simple tests for insufficient work and bad nonce
• ValidateOrphan
  • simple test for commitment hash
• validateSiacoins
  • test for timelocks, double-spends, and a few other conditions
• validateSiafunds
  • ditto
• validateFileContracts
  • check for invalid revisions, multiple storage proofs, and storage proofs in general
• validateArbitraryData
  • check foundation updates
• validateV2CurrencyValues
  • missing some straightforward checks here
• validateV2Siacoins
  • check for double-spends and ephemeral outputs
• validateV2Siafunds
  • ditto
• validateV2FileContracts
  • bunch of stuff here tbh, just start by testing anything involving a v2 contract resolution

I know this seems like a lot, but many of them just need a trivial test case, and many others have substantial overlap (e.g. two good tests for v1 and v2 contracts would add a ton of coverage).

For absolute beginners/newcomers, I recommend starting with validateHeader, ValidateOrphan, or MaxFutureTimestamp.