Why Splitwise tests financial logic in LLD - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why is testing financial logic critical in Splitwise?

Splitwise manages shared expenses and balances between users. Why is it important to thoroughly test the financial logic in such a system?

A Because testing helps improve the app's user interface colors and fonts.

B Because small calculation errors can lead to incorrect balances and user distrust.

C Because financial logic testing ensures the app loads faster on mobile devices.

D Because it helps the app connect to social media platforms more securely.

💡 Hint

Think about what happens if money amounts are wrong.

Financial logic must be accurate to maintain correct balances. Errors can cause users to owe or be owed wrong amounts, damaging trust.

❓ Architecture

intermediate

Which component should be tested for financial logic in Splitwise?

Splitwise has components for user interface, database, and financial calculations. Which component is most critical to test for financial logic correctness?

A The notification system that sends reminders.

B The user interface module that displays the balances.

C The database schema that stores user profiles.

D The financial calculation module that computes debts and balances.

💡 Hint

Focus on where the money math happens.

The financial calculation module performs the core logic of splitting expenses and updating balances, so it must be tested thoroughly.

❓ scaling

advanced

How does testing financial logic help Splitwise scale reliably?

As Splitwise grows to millions of users, why does testing financial logic become even more important?

A Because errors in calculations can multiply and affect many users, causing widespread issues.

B Because testing financial logic reduces the app's memory usage significantly.

C Because it helps the app load images faster for many users.

D Because it allows the app to support more languages automatically.

💡 Hint

Consider the impact of errors at large scale.

At scale, small bugs can affect many users simultaneously, leading to large financial discrepancies and loss of trust.

❓ tradeoff

advanced

What is a tradeoff when adding extensive financial logic tests in Splitwise?

Adding many detailed tests for financial logic improves accuracy but may have downsides. What is a common tradeoff?

A Increased risk of security vulnerabilities.

B Reduced accuracy in financial calculations.

C Longer development and testing time before releasing new features.

D Lower user engagement due to complex UI.

💡 Hint

Think about time and resources.

Extensive testing requires more time and effort, which can slow down feature releases but improves reliability.

❓ estimation

expert

Estimate the impact of a financial logic bug in Splitwise on user trust

Suppose a bug causes incorrect balances for 0.1% of users daily. If Splitwise has 10 million users, estimate how many users are affected daily and why testing financial logic is crucial.

A 10,000 users affected daily; testing prevents such widespread errors.

B 1,000 users affected daily; testing is not very important.

C 100,000 users affected daily; testing slows down the app.

D No users affected; bugs do not impact balances.

💡 Hint

Calculate 0.1% of 10 million.

0.1% of 10 million is 10,000 users. Such a large number affected daily can damage trust, so testing is vital.

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