Why different testing levels catch different bugs in Testing Fundamentals - Automation Benefits in Action
import pytest class Calculator: def add(self, a, b): # Bug: returns wrong sum intentionally return a + b + 1 def subtract(self, a, b): return a - b def multiply(self, a, b): return a * b def divide(self, a, b): if b == 0: raise ValueError("Cannot divide by zero") return a / b # Unit tests @pytest.mark.unit def test_add_bug(): calc = Calculator() result = calc.add(2, 3) assert result == 5, f"Expected 5 but got {result}" @pytest.mark.unit def test_subtract(): calc = Calculator() assert calc.subtract(5, 3) == 2 # Integration test @pytest.mark.integration def test_multiply_divide_bug(): calc = Calculator() mul = calc.multiply(4, 5) # 20 # Bug: divide returns wrong result if multiply used before # Simulate bug by altering divide to return wrong value if mul was called # For demo, we simulate bug by forcing wrong divide result divide_result = mul / 0 # This will raise ZeroDivisionError to simulate bug assert divide_result == 4, f"Expected 4 but got {divide_result}" # System test @pytest.mark.system def test_ui_display_bug(): # Simulate UI display bug by checking displayed result string displayed_result = "Result is 9" # Bug: should be 8 expected_display = "Result is 8" assert displayed_result == expected_display, f"UI display bug: expected '{expected_display}' but got '{displayed_result}'"
This test script uses pytest to automate testing at different levels.
The Calculator class has a bug in the add method (returns sum + 1).
Unit tests check individual functions like add and subtract. The test_add_bug test will fail because of the bug.
Integration test test_multiply_divide_bug simulates a bug when combining multiply and divide. It intentionally causes a division by zero error to represent a bug caught at integration level.
System test test_ui_display_bug simulates a UI display bug by comparing expected and actual displayed strings.
Using @pytest.mark decorators helps separate tests by level for clarity and selective running.
Now add data-driven testing with 3 different input sets for the add function to show the bug consistently.
Practice
Solution
Step 1: Understand testing levels
Unit testing checks small parts or units of code individually.Step 2: Compare options to definitions
System testing checks the whole system, integration testing checks combined parts, acceptance testing checks if requirements are met.Final Answer:
Unit Testing -> Option DQuick Check:
Individual parts = Unit Testing [OK]
- Confusing integration testing with unit testing
- Thinking system testing tests parts separately
- Mixing acceptance testing with unit testing
Solution
Step 1: Identify scope sizes
Unit testing checks smallest parts, integration testing checks combined parts, system testing checks whole system.Step 2: Arrange from smallest to largest
Correct order is Unit Testing, then Integration Testing, then System Testing.Final Answer:
Unit Testing -> Integration Testing -> System Testing -> Option BQuick Check:
Smallest to largest = A [OK]
- Reversing the order of testing levels
- Confusing integration with system testing
- Including acceptance testing in the wrong place
Solution
Step 1: Analyze bug context
The bug appears only when two modules interact, so it is related to combined parts.Step 2: Match testing level to bug type
Integration testing focuses on testing combined modules and their interactions.Final Answer:
Integration Testing -> Option AQuick Check:
Bug in combined modules = Integration Testing [OK]
- Choosing unit testing for interaction bugs
- Confusing system testing with integration testing
- Assuming acceptance testing finds module interaction bugs
Solution
Step 1: Understand the test scope
The tester tested the whole system but did not check module interactions.Step 2: Identify missing testing level
Integration testing specifically checks how modules work together, so it was likely skipped.Final Answer:
Integration Testing -> Option AQuick Check:
Missed module interaction = Integration Testing [OK]
- Confusing system testing with integration testing
- Assuming unit testing covers module interactions
- Thinking acceptance testing covers module integration
Solution
Step 1: Analyze bug conditions
The bug appears only when the full system runs with real user data, not in smaller tests.Step 2: Match testing level to scenario
System testing checks the entire system working together, often with realistic data, so it is best to find such bugs.Final Answer:
System Testing -> Option CQuick Check:
Full system with real data = System Testing [OK]
- Choosing unit or integration testing for full system bugs
- Confusing acceptance testing with system testing
- Ignoring the importance of real user data in tests
Ready to prove it?
Pass the test and this pattern moves unknown
