Skip to content

Covered Test Conditions

Jump to bottom
wanderer edited this page Sep 2, 2015 · 9 revisions

Here is a list of covered tests cases. Beware this test case maybe incomplete.

TODO

  • Light client proof tests
  • SOLIDITY TESTS
    • Contract Inheritance
    • contracts with store clears and suicides
    • make contract A call contract B method in which B destroys or call A to suicide
    • test all control structures and variable types
    • try to overflow variables when computing something
    • test Cryptographic Functions
    • test Contract Related functions
    • test Functions on addresses

Transaction

  • tx with too few rlp elements

  • tx with too many rlp elements

  • tx with extra bytes at the end that do not make up a valid rlp element

  • tx with an rlp element extending beyond the end (check for buffer overflow vulnerabilities) -ttTransactionTest.json Transaction*Overflow

  • tx where some rlp elements are lists when they shouldn't be

  • tx which is not an rlp list at all

  • tx where v < 27 in the sig

  • tx where v >= 31 in the sig

  • tx where r >= 2256 - 232 - 977 (ie. secp256k1p)

  • tx where s >= secp256k1n (ttTransactionTest.json TransactionWithSvalueOverflow )

  • tx with not enough gas to be valid, but whose execution has enough SSTORE clears to bring is back up (should be invalid) [stTransationTest.json Test ContractStoreClearsOOG]

  • tx going OOG with SSTORE clears [ stTransactionTestsFiller.json Test ContractStoreClearsOOG]

  • tx with internal CALL going OOG with SSTORE clears [stTransationTest.json InternlCallStoreClearsOOG]

  • tx with SSTORE clears and internal CALL going OOG with SSTORE clears [stTransationTest.json StoreClearsAnsInternlCallStoreClearsOOG]

  • similar for suicides [stTransactionTest.json Suicides*]

  • tx with address less than 20 bytes [ttTransactionTest.json AddressLessThan20]

  • tx with address more than 20 bytes [ttTransactionTest.json AddressMoreThan20]

  • tx with any value more than 32 bytes [ttTransactionTest.json Transaction*Overflow]

  • tx with any value other than address starting with one or more zero bytes [ttWrongRLPTransaction.json RLPElementWithFirstZeros]

  • tx with from address == to address and insufficient funds to transfer value

  • tx with from address == coinbase and insufficient funds to transfer value

  • CREATE transaction getting reverted [stTransactionTest.json CreateTransactionReverted]

  • CREATE message getting reverted for various reasons (OOG, 1024 [stInitCodeTest.json CallRecursiveContract, stTransactionTest.json CreateMessageReverted]

  • CALL an account using 50000 bytes of memory as input data 50000 times (checks for quadratic complexity vulns)

  • Same as above but for CREATE (the CREATE code should only return a few bytes)

  • Same as above but for SHA256/RIPEMD160/ECRECOVER

  • tx to precompiled contracts [stSystemOperationsTestFiller.json]

  • normal tx to address h160.max - 1. [stTransactionTest.json TransactionToAddressh160]

  • compute RIPEMD160 (CALL to 2), SSTORE, and then retrieve should be 32bytes. Same with ECRECOVER [stSystemOperationsTestFiller.json, stPreCompiledContracts.json]

  • SSTORE maxrefund is floor(50%) [stRefundTest.json]

VM

  • Zero-size memory expansions for CALL, CALLCODE, CREATE, CODECOPY CALLDATACOPY, EXTCODECOPY, SHA3
  • All opcodes using addresses, where the address input is greater than 2^160, particularly where the address mod 2^160 is a "useful" address
  • More SHA3 gas cost tests (only 1 test checks data size cost)
  • PUSH instructions at the end of code with some data missing
  • Memory with arbitrary index and size 0 (cost 0)
  • JUMP onto JUMP
  • dynamic JUMP onto a jump destination which is the destination of a static JUMP, but not a JUMPDEST. For example, PUSH1 2 PUSH1 4 ADD JUMP PUSH1 3 PUSH1 0 MSTORE 32 0 RETURN PUSH1 6 JUMP should return 3
  • Memory expansion that would OOG execution at depth = 1024 for call/create/callcode (eg. doing (call 5 5 5 0 3**160 0 0) should go OOG even at depth 1024
  • Memory expansion that would OOG execution with insufficient balance for call/creat (eg. doing (create 3160 0 3160) should go OOG even given insufficient balance

Transaction execution tests

  • Create constract: (stInitCodeTest)
  • OutOfGas
  • Stack underflow
  • Invalid JUMPDEST
  • RETURN
  • STOP [TransactionStopInitCode]
  • SUICIDE [TransactionSuicideInitCode]
  • recursive and depth checking [stRecursiveCreate.json]
  • Cannot jump onto a jump

RLP

  • empty trie.

Extreme-bound

  • Test all instructions with operands close to limits (2^160, 2^160 - 1, 2^256 - 1), one at a time; other operands should have reasonable values.
  • every opcode is tested with every permutation of 0,1,2^160, 2^160 - 1, 2^256 - 2, 2^256 - 1

From the YP

The address of the new account is defined as being the rightmost 160 bits of the SHA3 hash of RLP encoding of the structure containing only the sender and the nonce. In the unlikely event that the address is already in use, it is treated as a big-endian integer and incremented by one.

  • StateTests/stSystemOperationsTest.json - CreateHashCollision

State

  • tx sending to '' [stTransactionTest.json contract creation]
  • tx sending to '0000000000000000000000000000000000000000' [stTransactionTest.json TransactionSendingToZero]

CREATION

  • CREATE->CREATE->CREATE... chain [stRecursiveCreate.json recursiveCreate]
  • CALLing back from lower-level CREATES
  • CALL -> CREATE[ includes self-suicide ] -> CALL created
  • mixing in codebase as a suicided created address.

DEPTH vs LACK OF BALANCE

  • CALL/CREATE with VALUE > 0 @ depth = 1024, balance = 0

SUICIDE

  • call X ->{ call X -> SUICIDE Y } ->{ call X -> SUICIDE Y }[stSolidityTest.json SolidityTest::testContractSuicide, stTransactionTest.json SuicidesAndInternlCallSuicides]

EXP

Tests with dynamic exponent (e.g. taken from input data)

GAS

  • test if GAS instruction outputs correct values during program execution

JUMP

  • JUMPDEST as a first instruction in code
  • JUMP to first instruction after JUMP (the same or other one). This first instruction is or is not a JUMPDEST (2 cases)

Arithmetic

  • more SDIV, SMOD tests, e.g with arguments int256.min
  • ADDMOD, MULMOD with 256-bit overflow

Memory

  • StateTests/stMemoryTest.json)- Memory @32KB, 64KB, +/- 31, 32, 33 ....

CALLS

  • contract A calls B, B suicides, then A calls B again B and B returns its balance. Balance should be 0. This test if the VM subtracts B balance immediately on the suicide
  • contract A calls B, B suicides, then A calls B again B suicides again. The point here is to test that the suicide doesn't get rewarded twice.

Info

Test Types

Clone this wiki locally