03 Quiz: Testing Fundamentals - Unit Testing and Clean Code

Correct Answer: B

Code quality tools (Ruff, Pyright) check style and types, not correctness. They verify:

• ✅ Formatting (PEP8 compliance)
• ✅ Type hints are present and consistent
• ✅ Unused imports are removed

They do NOT verify:

• ❌ Logic is correct
• ❌ Edge cases are handled
• ❌ Functions return correct results

This is why we need tests - to verify that code actually works as intended, not just that it looks good.

Correct Answer: C

The testing pyramid recommends:

• 70% Unit tests (base of pyramid) - Fast, cheap, easy to debug
• 20% Module/Integration tests (middle) - Moderate speed and cost
• 10% End-to-End tests (top) - Slow, expensive, hard to debug

Why this distribution?

• Fast feedback loops: Unit tests run in milliseconds, enabling rapid iteration
• Easy debugging: When a unit test fails, you know exactly which function is broken
• Maintainability: Unit tests are easier to write and maintain than E2E tests
• Cost-effective: 50 unit tests run faster than 5 E2E tests

The pyramid shape reflects both the speed and quantity - more tests at the fast, cheap level.

Correct Answer: B

The test cone is an anti-pattern where the testing pyramid is inverted:

• Many E2E tests (top of pyramid becomes wide)
• Few or no unit tests (base of pyramid becomes narrow)

Problems with the test cone:

1. Slow feedback: Every change requires running slow E2E tests (minutes, not seconds)
2. Hard to debug: When E2E test fails, which of the 10 modules caused it?
3. Brittle: UI changes break many E2E tests
4. Vicious cycle: Tests are slow → developers avoid running them → bugs pile up

How it happens:

• “I don’t know how to write unit tests”
• “The UI is easy to click through manually”
• “Unit tests are too much work”

Solution: Learn to write unit tests properly (this lecture!) and build the pyramid correctly.

Correct Answer: B

Good unit tests should:

• ✅ Test in isolation: One function/method, no dependencies on other systems
• ✅ Be fast: Run in milliseconds (not seconds or minutes)
• ✅ Be clear: Easy to understand what’s being tested
• ✅ Be independent: Can run in any order

Unit tests should NOT:

• ❌ Start the entire application
• ❌ Connect to databases, APIs, or external services
• ❌ Require manual setup (like clicking through UI)
• ❌ Depend on other tests running first

Example:

# ✅ Good unit test - tests find_intersection() in isolation
def test_find_intersection_normal_angle():
    x, y, dist = find_intersection(test_data)
    assert dist > 0

# ❌ Not a unit test - requires starting Dash app
def test_full_application_flow():
    app = start_dash_app()  # Too slow!
    response = app.click_button()
    assert response.status == 200

Correct Answer: B

The AAA pattern is a standard structure for unit tests:

1. Arrange: Set up test data and conditions
2. Act: Call the function being tested
3. Assert: Verify the result matches expectations

Example:

def test_find_intersection_normal_angle():
    # ARRANGE: Set up test data
    x_road = np.array([0, 10, 20, 30])
    y_road = np.array([0, 2, 4, 6])
    angle = -10.0

    # ACT: Call the function
    x, y, dist = find_intersection(x_road, y_road, angle)

    # ASSERT: Verify the result
    assert x is not None
    assert dist > 0

Why this pattern?

• Readability: Clear structure makes tests easy to understand
• Debugging: Easy to see what’s being tested and what failed
• Consistency: All tests follow the same pattern

Correct Answer: B

Exhaustive testing is impossible because:

• Combinatorial explosion: Each parameter multiplies the number of test cases
• Infinite or near-infinite input spaces: Floats, strings, arrays have too many possible values
• Time constraints: Testing all combinations would take longer than the age of the universe

Example: A function with just 3 float parameters:

• Each parameter: ~1,000,000 possible values (conservative estimate)
• Total combinations: 1,000,000³ = 1 quintillion tests
• Time at 1ms per test: ~32 billion years

What we do instead:

• Smart testing strategies: Equivalence classes, boundary value analysis (Chapter 03 (Boundary Analysis))
• Risk-based testing: Focus on critical functionality
• Representative samples: Choose inputs that represent different scenarios

Key insight: You can never test everything, so you must be strategic about what you test.

Correct Answer: B

pytest provides automation and organization for testing:

With pytest:

• ✅ Auto-discovery: Finds all test_*.py files automatically
• ✅ Rich output: Shows exactly which test failed, line number, error type
• ✅ Organized reports: Clear pass/fail counts, execution time
• ✅ Test isolation: Each test runs independently
• ✅ CI/CD integration: Works seamlessly with GitHub Actions
• ✅ Simple syntax: Just use assert (no special methods needed)

Without pytest (manual testing):

• ❌ Have to call each test function manually
• ❌ Just get print statements (no structured output)
• ❌ No clear summary of what passed/failed
• ❌ Have to write your own error handling
• ❌ Tests might interfere with each other

Example comparison:

# Manual - primitive and tedious
def manual_test():
    if result != expected:
        print("FAILED")
        return False
    return True

# pytest - clean and powerful
def test_something():
    assert result == expected  # pytest handles the rest!

Correct Answer: C

One concept per test means each test verifies a single behavior or scenario.

Benefits:

• ✅ Clear failures: Test name tells you exactly what broke
• ✅ Easy debugging: No need to read entire test to find the issue
• ✅ Better organization: Related tests are grouped but separate
• ✅ Easier maintenance: Can modify/remove one concept without affecting others

Example of violation:

# ❌ Bad: Multiple concepts in one test
def test_find_intersection_everything():
    # Concept 1: downward angle
    assert find_intersection(..., -10.0)[0] is not None

    # Concept 2: vertical angle
    assert find_intersection(..., 90.0)[0] is None

    # Concept 3: empty arrays
    assert find_intersection([], [], -10.0)[0] is None

If this test fails, which concept is broken? You have to investigate.

Better approach:

# ✅ Good: One concept per test
def test_find_intersection_finds_intersection_for_downward_angle():
    assert find_intersection(..., -10.0)[0] is not None

def test_find_intersection_returns_none_for_vertical_angle():
    assert find_intersection(..., 90.0)[0] is None

def test_find_intersection_returns_none_for_empty_arrays():
    assert find_intersection([], [], -10.0)[0] is None

Now when a test fails: Test name immediately tells you which scenario is broken!

Correct Answer: C

Good test names are descriptive and follow a pattern:

• test_[function]_[scenario]_[expected_behavior]()

Analysis of each option:

A) test_1() - ❌ Tells you nothing

• What function? What scenario? What’s expected?
• Useless when test fails: “test_1 failed” means nothing

B) test_intersection() - ❌ Too vague

• Which function? Which scenario?
• Not specific enough to understand what failed

C) test_find_intersection_returns_none_for_empty_arrays() - ✅ Perfect!

• Function: find_intersection
• Scenario: empty arrays
• Expected behavior: returns None
• When it fails: “Empty array handling is broken” - immediately clear!

D) test_edge_case() - ❌ Not specific

• Which edge case?
• Which function?

Real-world impact:

# Unhelpful failure message:
❌ FAILED test_1

# Helpful failure message:
✅ FAILED test_find_intersection_returns_none_for_empty_arrays
   # You immediately know: "Oh, empty array handling is broken!"

Correct Answer: B

Fast tests enable rapid iteration:

With fast unit tests (milliseconds):

• ✅ Run tests after every code change
• ✅ Catch bugs immediately (within seconds)
• ✅ Stay in flow state (no waiting)
• ✅ Fix bugs while context is fresh
• ✅ Developers actually run tests (not avoided)

With slow E2E tests (minutes):

• ❌ Run tests infrequently (too slow)
• ❌ Bugs pile up between test runs
• ❌ Context switch while waiting (get coffee, check email)
• ❌ Fix bugs hours later (forgot what you changed)
• ❌ Developers avoid running tests (too slow)

Real-world comparison:

Change one line in find_intersection()

Fast feedback loop:
  Write code → Run 50 unit tests (0.5s) → Get immediate result
  → Fix if needed → Iterate rapidly

Slow feedback loop:
  Write code → Run 50 E2E tests (250s) → Wait 4+ minutes
  → Get distracted → Lose context → Harder to debug

Key principle: The faster the feedback, the more productive the developer.

Correct Answer: B

Multiple asserts are acceptable when they test the SAME concept:

✅ Good: Multiple asserts for one concept (coordinate validity)

def test_find_intersection_returns_valid_coordinates():
    """Test that coordinates are within expected bounds."""
    x, y, dist = find_intersection(...)

    # All verify SAME concept: valid coordinate bounds
    assert x is not None
    assert y is not None
    assert 0 <= x <= 30
    assert 0 <= y <= 6

Why this is OK: All asserts check “coordinate validity” - one concept with multiple aspects.

❌ Bad: Multiple asserts for different concepts

def test_find_intersection_coordinates_and_distance():
    x, y, dist = find_intersection(...)
    assert x > 0     # Concept 1: x position
    assert dist > 0  # Concept 2: distance (different!)

Why this is bad: Testing two independent concepts (position and distance).

Guideline:

• Same concept (coordinate validity, error handling) → Multiple asserts OK
• Different concepts (position vs. distance, input vs. output) → Split tests

Test yourself: If you can’t describe what the test checks in one sentence, split it.

Correct Answer: B

Test isolation means each test:

• ✅ Runs independently (doesn’t depend on other tests)
• ✅ Can run in any order
• ✅ Has no side effects (doesn’t modify global state)
• ✅ Doesn’t depend on external systems (databases, APIs, UI)

Why isolation matters:

1. Parallel execution:

# Isolated tests can run in parallel
$ pytest -n auto  # Runs tests simultaneously

2. Reliable debugging:

# ✅ Isolated: Can run just this one test
$ pytest tests/test_geometry.py::test_find_intersection_normal_angle

# ❌ Not isolated: Have to run test_setup() first
# Can't debug in isolation

3. No flaky tests:

# ❌ Not isolated - depends on test order
def test_a():
    global_state = 5  # Sets global state

def test_b():
    assert global_state == 5  # Fails if test_a doesn't run first!

# ✅ Isolated - each test sets up its own data
def test_a():
    local_state = 5
    assert local_state == 5

def test_b():
    local_state = 10
    assert local_state == 10

How pytest helps:

• Each test function runs in its own scope
• No shared state between tests
• Tests can run in any order (or in parallel)