Why testing prevents costly bugs in Blockchain / Solidity - Challenge Your Understanding

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of a smart contract function without testing

Consider this simple smart contract function that transfers tokens. What will be the output when calling transfer(50) if the sender has only 30 tokens?

Blockchain / Solidity

contract Token {
    mapping(address => uint) balances;

    function transfer(uint amount) public returns (string memory) {
        if (balances[msg.sender] >= amount) {
            balances[msg.sender] -= amount;
            return "Transfer successful";
        } else {
            return "Insufficient balance";
        }
    }
}

A "Insufficient balance"

B "Transfer failed due to gas limit"

C Transaction reverts with error

D "Transfer successful"

💡 Hint

Think about what happens if the sender does not have enough tokens.

The function checks if the sender's balance is enough. Since the sender has only 30 tokens but tries to transfer 50, the condition fails and the function returns "Insufficient balance".

🧠 Conceptual

intermediate

Why is testing important in blockchain development?

Which of the following best explains why testing smart contracts before deployment is crucial?

A Because bugs in smart contracts can cause irreversible financial loss

B Because testing increases the speed of blockchain transactions

C Because smart contracts can be easily updated after deployment

D Because testing reduces the size of the blockchain

💡 Hint

Think about the nature of blockchain transactions and immutability.

Smart contracts are immutable once deployed, so bugs cannot be fixed easily. Bugs can cause permanent loss of funds or unintended behavior, making testing essential.

🔧 Debug

advanced

Identify the bug causing incorrect token balance update

This smart contract function is supposed to transfer tokens from sender to receiver. What is the bug causing incorrect balances after transfer?

Blockchain / Solidity

function transfer(address to, uint amount) public {
    require(balances[msg.sender] >= amount, "Not enough tokens");
    balances[to] += amount;
    balances[msg.sender] -= amount;
}

A The order of updating balances is wrong; sender balance should be reduced before receiver is increased

B The function lacks a return statement indicating success or failure

C The function does not check for overflow when increasing receiver balance

D The require statement should check if receiver has enough tokens

💡 Hint

Consider what happens if the receiver's balance is very large before adding amount.

Without checking for overflow, adding amount to receiver's balance can wrap around causing incorrect balances. This is a common bug in smart contracts.

📝 Syntax

advanced

Syntax error in smart contract function

Which option contains the correct syntax for a Solidity function that returns the balance of an address?

A function getBalance(address user) public returns (uint) { return balances[user]; }

B function getBalance(address user) public view returns (uint) { return balances[user]; }

C function getBalance(address user) public pure returns (uint) { return balances[user]; }

D function getBalance(address user) returns uint { return balances[user]; }

💡 Hint

Think about the function type that reads state without modifying it.

The function reads the contract state without modifying it, so it must be marked as 'view'. Option B is correct syntax. Option B misses 'view', C uses 'pure' which disallows state access, D misses visibility and parentheses.

🚀 Application

expert

Effect of missing tests on deployed smart contract

A developer deployed a smart contract without thorough testing. After deployment, a bug caused incorrect token transfers. What is the most likely consequence?

A The developer can easily patch the contract and fix the bug immediately

B The bug will only affect test networks and not the main blockchain

C The blockchain network will automatically detect and correct the bug

D Users may lose tokens permanently and the bug cannot be fixed without redeploying

💡 Hint

Remember that smart contracts are immutable once deployed on mainnet.

Smart contracts on blockchain are immutable. Bugs cannot be fixed by patching the contract. Users may lose tokens permanently, and fixing requires redeploying a new contract and migrating users.

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