Why Splitwise tests financial logic in LLD - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to calculate the total amount owed by a user.

LLD

total_owed = sum(expense.amount for expense in user.expenses if expense.paid_by != [1])

Drag options to blanks, or click blank then click option'

Auser.id

Bexpense.id

Cexpense.paid_by

Duser.name

Attempts:

3 left

💡 Hint

Common Mistakes

Using the expense ID instead of the payer's ID.

Comparing with user name instead of user ID.

The total amount owed by a user is the sum of expenses not paid by the user, identified by user.id.

2fill in blank

medium

Complete the code to split an expense evenly among participants.

LLD

share = expense.amount / [1]

Drag options to blanks, or click blank then click option'

Asum(expense.participants)

Bexpense.amount

Cexpense.paid_by

Dlen(expense.participants)

Attempts:

3 left

💡 Hint

Common Mistakes

Dividing by the amount itself.

Using the payer instead of participants count.

The expense amount is divided evenly by the number of participants to find each person's share.

3fill in blank

hard

Fix the error in the code that calculates the balance for each user.

LLD

balance = user.paid_amount - sum(user.owed_amounts.get([1], 0) for user in users)

Drag options to blanks, or click blank then click option'

Auser.name

Buser.id

Cexpense.id

Duser.paid_amount

Attempts:

3 left

💡 Hint

Common Mistakes

Using user.name which may not be unique.

Using expense.id which is unrelated.

To get the owed amount for the specific user, use user.id as the key in owed_amounts dictionary.

4fill in blank

hard

Fill both blanks to create a dictionary of user balances where keys are user IDs and values are their net balances.

LLD

balances = {user.[1]: user.[2] for user in users}

Drag options to blanks, or click blank then click option'

Aid

Bbalance

Cname

Dpaid_amount

Attempts:

3 left

💡 Hint

Common Mistakes

Using user names as keys which may not be unique.

Using paid_amount instead of balance for values.

The dictionary keys should be user IDs and values should be their net balances.

5fill in blank

hard

Fill all three blanks to filter expenses where the amount is greater than zero and the payer is not the current user.

LLD

filtered_expenses = [expense for expense in expenses if expense.[1] > [2] and expense.[3] != current_user.id]

Drag options to blanks, or click blank then click option'

Aamount

B0

Cpaid_by

Duser_id

Attempts:

3 left

💡 Hint

Common Mistakes

Using user_id instead of paid_by for payer.

Checking amount less than zero.

We filter expenses with amount greater than zero and exclude those paid by the current user.

Practice

1. Why does Splitwise test its financial logic thoroughly?

easy

A. To ensure money calculations are accurate and users trust the app

B. To make the app load faster

C. To improve the app's color scheme

D. To add more social features

Solution

1. Step 1: Understand the purpose of financial logic testing

   Financial logic testing ensures that calculations involving money are correct and reliable.

2. Step 2: Connect testing to user trust

   Accurate calculations build user trust because users rely on the app for managing shared expenses.

3. Final Answer:

   To ensure money calculations are accurate and users trust the app -> Option A

4. Quick Check:

   Financial accuracy = User trust [OK]

Hint: Focus on why money accuracy matters most [OK]

Common Mistakes:

• Confusing financial logic with UI improvements
• Thinking testing improves app speed
• Assuming testing adds features

2. Which part is NOT typically included in a good test for financial logic in Splitwise?

easy

A. Changing the app's theme colors during the test

B. Action that performs a money calculation

C. Verification that results match expected values

D. Setup of initial balances and debts

Solution

1. Step 1: Identify typical test components

   Good tests include setup, action, and verification steps to check correctness.

2. Step 2: Recognize unrelated actions

   Changing theme colors is unrelated to financial logic and does not belong in such tests.

3. Final Answer:

   Changing the app's theme colors during the test -> Option A

4. Quick Check:

   Test steps = Setup + Action + Verify [OK]

Hint: Remember tests focus on logic, not UI changes [OK]

Common Mistakes:

• Including UI changes as part of logic tests
• Ignoring verification steps
• Skipping setup of test data

3. Given this test snippet for Splitwise financial logic:

initial_balance = 100
expense = 40
new_balance = initial_balance - expense
assert new_balance == 60

What will happen if the assertion fails?

medium

A. The test passes silently

B. An error is raised indicating a failed test

C. The app crashes permanently

D. The balance is automatically corrected

Solution

1. Step 1: Understand assertion behavior

   An assertion checks if a condition is true; if false, it raises an error.

2. Step 2: Connect assertion failure to test result

   If the assertion fails, the test framework reports an error indicating failure.

3. Final Answer:

   An error is raised indicating a failed test -> Option B

4. Quick Check:

   Assertion fail = Error raised [OK]

Hint: Remember assert stops test on failure [OK]

Common Mistakes:

• Thinking assertion failure passes silently
• Assuming app crashes permanently
• Believing balance auto-corrects

4. In a Splitwise test, this code snippet is used:

balance = 50
expense = '30'
new_balance = balance - expense

What is the main problem here?

medium

A. The balance variable is not initialized

B. The expense should be added, not subtracted

C. Subtracting a string from an integer causes a type error

D. The new_balance variable is unused

Solution

1. Step 1: Identify data types involved

   balance is an integer, expense is a string representing a number.

2. Step 2: Understand subtraction operation rules

   Subtracting a string from an integer is invalid and causes a type error in most languages.

3. Final Answer:

   Subtracting a string from an integer causes a type error -> Option C

4. Quick Check:

   Type mismatch in subtraction = Error [OK]

Hint: Check data types before arithmetic operations [OK]

Common Mistakes:

• Ignoring type mismatch errors
• Assuming variables are uninitialized
• Confusing addition and subtraction

5. Splitwise wants to test a complex scenario where multiple users owe each other different amounts. Which approach best ensures the financial logic is tested correctly?

hard

A. Skip tests and rely on manual checks

B. Test only single user transactions repeatedly

C. Test UI elements without checking calculations

D. Create test cases with multiple users, set debts, perform calculations, and verify final balances

Solution

1. Step 1: Understand the need for realistic test scenarios

   Testing multiple users with debts simulates real app usage and catches complex bugs.

2. Step 2: Verify calculations and final balances

   Performing calculations and verifying results ensures the financial logic works end-to-end.

3. Final Answer:

   Create test cases with multiple users, set debts, perform calculations, and verify final balances -> Option D

4. Quick Check:

   Realistic multi-user tests = Accurate financial logic [OK]

Hint: Test real-world scenarios with multiple users [OK]

Common Mistakes:

• Testing only simple cases
• Skipping automated tests
• Focusing on UI over logic