Why testing prevents costly bugs in Blockchain / Solidity - Visual Breakdown

Concept Flow - Why testing prevents costly bugs

Write Code

↓

Write Tests

↓

Run Tests

↓

Tests Pass?

No→Fix Bugs

↓

Re-run Tests

↓

Deploy Code

↓

Code Works Safely

This flow shows how writing and running tests before deployment helps catch bugs early, preventing costly errors later.

Execution Sample

Blockchain / Solidity

function transfer(amount) {
  if (balance >= amount) {
    balance -= amount;
    return true;
  } else {
    return false;
  }
}

This simple blockchain transfer function checks if balance is enough before subtracting amount.

Execution Table

Step	balance	amount	Condition (balance >= amount)	Action	Return Value
1	100	50	100 >= 50 is True	balance = 100 - 50 = 50	true
2	50	60	50 >= 60 is False	No subtraction	false
3	50	50	50 >= 50 is True	balance = 50 - 50 = 0	true
4	0	10	0 >= 10 is False	No subtraction	false

💡 All test cases run to check transfer function behavior with different amounts.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4
balance	100	50	50	0	0
amount	-	50	60	50	10

Key Moments - 2 Insights

Why do we check the condition 'balance >= amount' before subtracting?

Because if we subtract without checking, balance could go negative causing errors. See execution_table step 2 where condition is false and no subtraction happens.

What happens if tests are not run before deployment?

Bugs like allowing negative balance could go unnoticed, causing costly failures after deployment. The flow shows tests catch bugs early before deploy.

Visual Quiz - 3 Questions

Look at the execution_table at Step 3, what is the balance after the transfer?

A 0

B 50

C 100

D 60

💡 Hint

Check the 'Action' and 'balance' columns at Step 3 in execution_table.

At which step does the condition 'balance >= amount' become false for the first time?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Look at the 'Condition' column in execution_table to find the first false.

If the condition check was removed, what would happen to balance at Step 2?

A transfer returns false

B balance would become negative

C balance stays the same

D transfer returns true

💡 Hint

Without condition, subtraction happens regardless, see variable_tracker for balance changes.

Concept Snapshot

Testing in blockchain code means writing checks before deployment.
Run tests to catch bugs early.
Prevents costly errors like negative balances.
Always verify conditions before state changes.
Fix bugs before deploying to keep code safe.

Full Transcript

This visual shows why testing blockchain code prevents costly bugs. We start by writing code and tests, then run tests. If tests fail, we fix bugs and re-run tests until all pass. Only then do we deploy code safely. The example transfer function checks if balance is enough before subtracting. The execution table traces four test cases showing when transfers succeed or fail. The variable tracker shows how balance changes step by step. Key moments explain why condition checks matter and why testing before deployment is critical. The quiz asks about balance values and condition results to reinforce learning. Testing helps catch errors early, avoiding expensive problems after deployment.

Practice

1. Why is testing especially important in blockchain development?

easy

A. Because it helps find bugs early to avoid costly mistakes

B. Because blockchain code never changes once written

C. Because testing slows down the development process

D. Because blockchain does not handle real assets

Solution

1. Step 1: Understand blockchain risks

   Blockchain handles real assets and trust, so bugs can cause big losses.

2. Step 2: Role of testing

   Testing finds bugs early, preventing costly mistakes before deployment.

3. Final Answer:

   Because it helps find bugs early to avoid costly mistakes -> Option A

4. Quick Check:

   Testing prevents costly bugs = C [OK]

Hint: Testing finds bugs early to save money and trust [OK]

Common Mistakes:

• Thinking blockchain code never changes
• Believing testing slows development
• Ignoring real asset risks

2. Which of the following is the correct syntax to define a simple test function in Solidity?

easy

A. test function balance() { /* code */ }

B. function testBalance() public { /* test code */ }

C. def testBalance(): pass

D. function testBalance() private { /* test code */ }

Solution

1. Step 1: Recall Solidity function syntax

   Functions start with 'function', name, visibility, and body in braces.

2. Step 2: Check options

   function testBalance() public { /* test code */ } matches Solidity syntax with 'public' visibility for test functions.

3. Final Answer:

   function testBalance() public { /* test code */ } -> Option B

4. Quick Check:

   Solidity test function syntax = B [OK]

Hint: Solidity functions start with 'function' and visibility [OK]

Common Mistakes:

• Using Python syntax in Solidity
• Missing 'function' keyword
• Using wrong visibility for test functions

3. Consider this Solidity test snippet:

uint balance = 100;
function testWithdraw() public {
    uint amount = 50;
    balance -= amount;
    assert(balance == 50);
}

What will happen when testWithdraw() runs?

medium

A. The test passes because balance equals 50 after withdrawal

B. The test fails because balance is not updated

C. The code causes a compilation error

D. The test throws a runtime exception

Solution

1. Step 1: Analyze balance update

   Initial balance is 100, subtract 50, new balance is 50.

2. Step 2: Check assertion

   Assert checks balance == 50, which is true, so test passes.

3. Final Answer:

   The test passes because balance equals 50 after withdrawal -> Option A

4. Quick Check:

   balance after subtract 50 = 50 [OK]

Hint: Check variable updates before assertions [OK]

Common Mistakes:

• Assuming balance is unchanged
• Confusing compile errors with runtime logic
• Ignoring assert condition

4. This Solidity test function is meant to check if a user can withdraw funds:

function testWithdraw() public {
    uint balance = 100;
    uint amount = 150;
    balance -= amount;
    assert(balance >= 0);
}

What is the main problem with this test?

medium

A. The test function is missing visibility

B. The assert condition is always true

C. It allows balance to go negative, which is invalid in Solidity

D. The amount is less than balance, so test is useless

Solution

1. Step 1: Check balance subtraction

   Subtracting 150 from 100 causes underflow (negative balance).

2. Step 2: Understand Solidity behavior

   Solidity unsigned integers cannot be negative; underflow causes error or wrap.

3. Final Answer:

   It allows balance to go negative, which is invalid in Solidity -> Option C

4. Quick Check:

   Unsigned int underflow = error [OK]

Hint: Check for underflow or overflow in tests [OK]

Common Mistakes:

• Ignoring unsigned integer limits
• Assuming assert always passes
• Missing visibility keyword

5. You want to write automated tests for a smart contract that manages token transfers. Which approach best prevents costly bugs?

hard

A. Write tests that check only successful transfers

B. Write tests only after deployment

C. Skip tests and rely on manual code review

D. Write tests that check both successful and failed transfers

Solution

1. Step 1: Understand test coverage needs

   Testing only successes misses bugs in failure cases.

2. Step 2: Importance of failure tests

   Tests for failed transfers catch edge cases and prevent costly errors.

3. Final Answer:

   Write tests that check both successful and failed transfers -> Option D

4. Quick Check:

   Test successes and failures = D [OK]

Hint: Test both success and failure cases to catch all bugs [OK]

Common Mistakes:

• Testing only success cases
• Skipping automated tests
• Testing after deployment too late