Why Splitwise tests financial logic in LLD - Why This Architecture

Problem Statement

When financial calculations are incorrect, users lose trust and money can be misallocated. Small errors in splitting bills or rounding can cause disputes and damage the app's reputation.

Solution

Splitwise tests financial logic by writing automated tests that verify calculations for splitting expenses, rounding, and settling debts. This ensures accuracy and consistency in all money-related operations before changes reach users.

Architecture

Codebase

→Financial Logic

↓

Developers

This diagram shows how developers write code that includes financial logic, which is then verified by automated tests producing test results to ensure correctness.

Trade-offs

✓ Pros

→

Prevents costly financial errors that harm user trust.

→

Catches bugs early before deployment, reducing hotfixes.

→

Ensures consistent behavior across different devices and updates.

✗ Cons

→

Requires extra development time to write and maintain tests.

→

Complex financial rules can make tests hard to cover fully.

→

May slow down deployment pipelines due to test execution time.

Always use when handling money or financial calculations, especially if the app manages user debts or payments at scale (thousands+ users).

Not needed for non-financial features or prototypes without real money handling.

Real World Examples

Splitwise

Tests financial logic to ensure accurate splitting of bills and debt settlements among friends, preventing disputes.

Stripe

Extensive financial logic tests to guarantee correct payment processing and fee calculations.

Venmo

Tests ensure peer-to-peer payment calculations and balance updates are accurate and secure.

Code Example

The before code lacks tests, risking unnoticed errors. The after code adds unit tests that check the split method for correct division and rounding, ensuring financial logic correctness.

LLD

### Before: No tests for financial logic
class Expense:
    def __init__(self, total, participants):
        self.total = total
        self.participants = participants

    def split(self):
        return self.total / len(self.participants)


### After: Adding tests to verify splitting logic
import unittest

class Expense:
    def __init__(self, total, participants):
        self.total = total
        self.participants = participants

    def split(self):
        # Round to 2 decimals for currency
        return round(self.total / len(self.participants), 2)

class TestExpense(unittest.TestCase):
    def test_split_even(self):
        expense = Expense(100, ['A', 'B', 'C', 'D'])
        self.assertEqual(expense.split(), 25.00)

    def test_split_rounding(self):
        expense = Expense(100, ['A', 'B', 'C'])
        self.assertEqual(expense.split(), 33.33)

if __name__ == '__main__':
    unittest.main()

Alternatives

Manual Testing

Relies on human testers to verify financial calculations instead of automated tests.

Use when: Only for very small projects or early prototypes where automation is not feasible.

Property-Based Testing

Tests financial logic by checking properties and invariants over many random inputs rather than fixed examples.

Use when: When financial rules are complex and need broad input coverage.

Summary

Financial logic errors cause user distrust and money loss.

Automated tests verify calculations and rounding to ensure accuracy.

Splitwise and other payment apps rely on these tests to prevent disputes.

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