📖 Scenario: Imagine you are building a simple blockchain smart contract simulation. Bugs in blockchain code can cause huge financial losses. Testing your code carefully helps catch mistakes early, saving money and trust.
🎯 Goal: You will create a small blockchain transaction record, set a limit for valid transactions, filter out invalid ones using a comprehension, and print the valid transactions. This shows how testing and filtering prevent costly errors.
📋 What You'll Learn
Create a dictionary called transactions with exact entries for 5 users and their transaction amounts
Create a variable called max_amount set to 1000
Use a dictionary comprehension called valid_transactions to keep only transactions less than or equal to max_amount
Print the valid_transactions dictionary
💡 Why This Matters
🌍 Real World
In blockchain development, testing transaction limits prevents sending or accepting invalid amounts that could cause financial loss.
💼 Career
Blockchain developers must write safe, tested code to avoid costly bugs that can damage reputation and cause legal issues.
Progress0 / 4 steps
1
DATA SETUP: Create the transactions dictionary
Create a dictionary called transactions with these exact entries: 'Alice': 500, 'Bob': 1500, 'Charlie': 700, 'Diana': 1200, 'Eve': 300
Blockchain / Solidity
Hint
Use curly braces {} to create a dictionary with the exact keys and values.
2
CONFIGURATION: Set the maximum allowed transaction amount
Create a variable called max_amount and set it to 1000
Blockchain / Solidity
Hint
Just assign 1000 to the variable max_amount.
3
CORE LOGIC: Filter valid transactions using dictionary comprehension
Create a dictionary comprehension called valid_transactions that includes only entries from transactions where the amount is less than or equal to max_amount
Blockchain / Solidity
Hint
Use {key: value for key, value in dict.items() if condition} format.
4
OUTPUT: Print the valid transactions
Write a print statement to display the valid_transactions dictionary
Blockchain / Solidity
Hint
Use print(valid_transactions) to show the filtered dictionary.
Practice
(1/5)
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
Step 1: Understand blockchain risks
Blockchain handles real assets and trust, so bugs can cause big losses.
Step 2: Role of testing
Testing finds bugs early, preventing costly mistakes before deployment.
Final Answer:
Because it helps find bugs early to avoid costly mistakes -> Option A
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
Step 1: Recall Solidity function syntax
Functions start with 'function', name, visibility, and body in braces.
Step 2: Check options
function testBalance() public { /* test code */ } matches Solidity syntax with 'public' visibility for test functions.
Final Answer:
function testBalance() public { /* test code */ } -> Option B
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
Step 1: Analyze balance update
Initial balance is 100, subtract 50, new balance is 50.
Step 2: Check assertion
Assert checks balance == 50, which is true, so test passes.
Final Answer:
The test passes because balance equals 50 after withdrawal -> Option A
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
Step 1: Check balance subtraction
Subtracting 150 from 100 causes underflow (negative balance).
Step 2: Understand Solidity behavior
Solidity unsigned integers cannot be negative; underflow causes error or wrap.
Final Answer:
It allows balance to go negative, which is invalid in Solidity -> Option C
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
Step 1: Understand test coverage needs
Testing only successes misses bugs in failure cases.
Step 2: Importance of failure tests
Tests for failed transfers catch edge cases and prevent costly errors.
Final Answer:
Write tests that check both successful and failed transfers -> Option D
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
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.