Skip to content

TESTING.md

Latest commit

 

History

History
173 lines (107 loc) · 5.31 KB

TESTING.md

File metadata and controls

173 lines (107 loc) · 5.31 KB

P2P Test:

Check the main section of p2p/p2p_node.py and p2p/p2p_tracker.py for instructions on running tests for P2P implementation.

Blockchain Test Suite

Each test exercises a distinct rule of your blockchain implementation so you can quickly see what is being verified and why failures might occur.

Following tests are written in test/test_blockchain.py or application/script.py

1. test_genesis_has_height_0_and_single_block

Goal Verify that a brand‑new Blockchain starts with exactly one block—the genesis block—and that balances are zero.
Setup 
bc = Blockchain(difficulty=2)
chain = bc.get_main_chain()

Assertions

  1. len(chain) == 1 – only genesis exists.
  2. chain[0].index == 0 – genesis index is 0.
  3. bc.get_balance("anyone") == 0 – no funds are pre‑minted.

Why it matters
A proper genesis block anchors all future validation logic; an incorrect height or stray balance would undermine consensus and accounting.

2. test_assign_and_transfer_flow

Ensures normal mint → spend flow works.

  1. Create alice, bob key pairs.
  2. Mine a block containing an ASSIGN giving Alice 10.
  3. Mine a second block transferring 4 from Alice to Bob.
  4. Check resulting balances: alice 6, bob 4.

Key checks

  • _add_block accepts both blocks (valid PoW, signatures, and funds).
  • Ledger correctly tracks incremental balances across multiple blocks.

3. test_insufficient_funds_is_rejected

Rejects overspending.

  1. Alice receives 5.
  2. Alice tries to send 10 to Bob in the next block.
  3. Blockchain.add_block must return False; balances stay alice 5, bob 0.

Confirms that the UTXO/ledger rules prevent negative balances.

4. test_bad_signature_rejected

Detects missing or invalid signatures.

  • Alice is assigned 3 coins.
  • A transfer tx is created without tx.sign().
  • Block containing the unsigned tx is rejected; Bob’s balance remains 0.

Ensures cryptographic authentication is enforced.

5. test_pow_enforced_on_add_block

Guards against fake hashes.

  • Craft a block but manually overwrite blk.hash = "abc" (no mining).
  • _is_valid_pow should fail ⇒ add_block returns False.

Validates that PoW is re‑verified by each node, not trusted from sender.

6. test_longest_chain_wins

Simple fork‑choice rule.

genesis ─ b1 ─ b2a ─ b3a   ← main (length 3 after genesis)
           └─ b2b          ← shorter fork (length 2)

After adding both branches:

  • main_head == b3a.hash.
  • len(get_main_chain()) == 4 (genesis + 3 blocks).

Confirms longest‑chain‑wins consensus.

7. test_prune_old_forks

Prunes stale forks that lag the main chain by ≥ 7 blocks (parameter chosen in Blockchain).

  1. Build branch A 8 blocks ahead.
  2. Build branch B only 1 block ahead.
  3. Once the gap reaches 7, branch B is removed from bc.chains.

Keeps memory usage bounded and resists fork spam.

8. test_node_mines_from_mempool_and_clears_it

End‑to‑end node mining loop (single node, no P2P).

  • Fill node.mempool with one ASSIGN (Alice 5) and one transfer (Alice→Bob 2).
  • Background miner should eventually find a nonce, commit a block, and empty the mempool.
  • Final balances: alice 3, bob 2.

Shows integration between mempool, miner thread, and ledger.

9. test_mine_using_p2p_network

Three nodes & a tracker:

  1. Each node has its own port; all register with P2PTracker.
  2. Mempools contain overlapping assignments and transfers among Alice, Bob, Charlie.
  3. After ~60 s the nodes should have mined/propagated enough blocks to agree on balances (printed for manual inspection).

Primary aim – Validate networking, gossip, assert creation of forks and rejection of some transactions and consensus convergence in a live mini‑network.

10. test_malicious_block_rejected

Stress‑tests PoW verification on a deep chain:

  • Build 99 honest blocks.
  • Forge block 100 with the malicious mining branch (inverted PoW condition ⇒ bad hash).
  • add_block must reject it; main_head stays at height 99.

Prevents selective rule‑bending at arbitrary heights.

11. test_multiple_transactions_in_block

Checks intra‑block ordering and cumulative balance logic.

Block #1 includes three tx in sequence:

  1. ASSIGN 10 → Alice
  2. Alice → Bob 4
  3. Alice → Charlie 3

Expected final balances (after the single block):

  • Alice: 3
  • Bob: 4
  • Charlie: 3

Assures that the validator updates balances sequentially within one block.

12. test_end2end

This is an end-to-end inntegration test for the Wallet class and the blockchain application. This expects the blockchain application to be up.

Blockchain application can be started as: python3 -m application.application <application_ip> <application_port> <tracker_ip> <tracker_port> <list_of_blockchain_node_ip_and_ports>

This test starts by creating to wallets for Alice and Bob. It then connects the wallets to the network. This should give each of them 10 coins, which is confirmed for fetching the blockchain and confirming the balance. After this, we attempt to create a transaction between the wallets and assert the wallet balances.