Why Unit testing in Testing Fundamentals? - Purpose & Use Cases

The Big Idea

What if your code could check itself every time you change it?

The Scenario

Imagine you just wrote a small piece of code to calculate discounts for a shopping app. Every time you change something, you open the app and try different prices manually to see if the discount works correctly.

The Problem

This manual checking is slow and tiring. You might forget some price cases or make mistakes while testing. If the code changes often, you waste a lot of time repeating the same checks, and bugs can sneak in unnoticed.

The Solution

Unit testing lets you write small automatic checks for each part of your code. These tests run quickly and tell you immediately if something breaks, so you don't have to test everything by hand every time.

Before vs After

✗ Before

Run app, enter price 100, check discount manually
Run app, enter price 200, check discount manually

✓ After

assert calculate_discount(100) == 10
assert calculate_discount(200) == 20

What It Enables

Unit testing makes your code safer and saves time by catching errors early with automatic checks.

Real Life Example

A developer changes a function to add a new feature. Thanks to unit tests, they quickly see if the old discount calculations still work without opening the app and clicking around.

Key Takeaways

Manual testing is slow and error-prone.

Unit tests automate checks for small code parts.

They help catch bugs early and speed up development.

Practice

1. What is the main purpose of unit testing in software development?

easy

A. To deploy the software to users

B. To test the entire software system at once

C. To check small parts of code work correctly

D. To design the user interface

Solution

1. Step 1: Understand unit testing scope

   Unit testing focuses on testing small, individual parts of code, like functions or methods.

2. Step 2: Compare with other testing types

   Testing the entire system is integration or system testing, not unit testing.

3. Final Answer:

   To check small parts of code work correctly -> Option C

4. Quick Check:

   Unit testing = small code parts check [OK]

Hint: Unit tests check small code parts, not whole system [OK]

Common Mistakes:

• Confusing unit testing with system testing
• Thinking unit tests check UI or deployment
• Believing unit tests run the full application

2. Which of the following is the correct syntax for a simple unit test assertion in Python using assert?

easy

A. assert add(2, 3) == 5

B. assert add(2, 3) = 5

C. assert(add(2, 3) = 5)

D. assert add(2, 3) equals 5

Solution

1. Step 1: Recall Python assert syntax

   Python uses assert expression where expression must be True for test to pass.

2. Step 2: Check each option

   assert add(2, 3) == 5 uses correct syntax: assert add(2, 3) == 5. assert add(2, 3) = 5 uses single = which is assignment, invalid here. assert(add(2, 3) = 5) uses single = which is assignment, invalid syntax. assert add(2, 3) equals 5 uses invalid keyword 'equals'.

3. Final Answer:

   assert add(2, 3) == 5 -> Option A

4. Quick Check:

   assert with == for comparison [OK]

Hint: Use 'assert expression' with '==' for comparison in Python [OK]

Common Mistakes:

• Using single '=' instead of '==' in assert
• Writing assert with invalid keywords
• Adding unnecessary parentheses in assert

3. Given the Python function and test below, what will be the test result?

def multiply(a, b):
    return a * b

assert multiply(3, 4) == 12
assert multiply(0, 5) == 0
assert multiply(-1, 3) == -3
assert multiply(2, 2) == 5

medium

A. The last assertion fails

B. All assertions pass

C. The first assertion fails

D. The second assertion fails

Solution

1. Step 1: Evaluate each assertion

   multiply(3,4) = 12 matches expected 12 (pass). multiply(0,5) = 0 matches 0 (pass). multiply(-1,3) = -3 matches -3 (pass). multiply(2,2) = 4 but expected 5 (fail).

2. Step 2: Identify failing assertion

   The last assertion expects 5 but function returns 4, so it fails.

3. Final Answer:

   The last assertion fails -> Option A

4. Quick Check:

   4 != 5 causes failure [OK]

Hint: Check each assert expected vs actual carefully [OK]

Common Mistakes:

• Assuming all assertions pass without checking values
• Confusing multiplication results
• Ignoring the last assertion

4. Identify the error in the following Python unit test code:

def divide(a, b):
    return a / b

assert divide(10, 2) == 5
assert divide(5, 0) == 0

medium

A. The function should return integer only

B. Division by zero causes runtime error

C. The first assertion is incorrect

D. Assertions are missing parentheses

Solution

1. Step 1: Analyze function behavior

   Function divides a by b. Dividing by zero is not allowed and causes an error.

2. Step 2: Check assertions

   First assertion divides 10 by 2, which is valid. Second assertion divides 5 by 0, which causes a runtime ZeroDivisionError.

3. Final Answer:

   Division by zero causes runtime error -> Option B

4. Quick Check:

   Divide by zero error in second assert [OK]

Hint: Watch for zero division in tests [OK]

Common Mistakes:

• Ignoring division by zero error
• Thinking assertions need parentheses in Python
• Assuming function returns only integers

5. You want to write a unit test for a function that returns the maximum number from a list. Which test case below best checks the function handles an empty list correctly?

hard

A. assert max_number([-1, -2]) == -1

B. assert max_number([1, 2, 3]) == 3

C. assert max_number([0]) == 0

D. assert max_number([]) == None

Solution

1. Step 1: Understand the edge case

   An empty list has no maximum value, so the function should handle this gracefully, often by returning None or raising an error.

2. Step 2: Evaluate test cases

   assert max_number([]) == None tests the empty list case expecting None, which is appropriate. Other options test normal lists, not empty.

3. Final Answer:

   assert max_number([]) == None -> Option D

4. Quick Check:

   Empty list test expects None [OK]

Hint: Test empty inputs with None or error expected [OK]

Common Mistakes:

• Not testing empty list edge case
• Using normal list tests for empty case
• Assuming empty list returns zero