Unit 3.1: Levels of Testing - Unit & Integration

1. Unit Testing: The First Line of Defense

Definition: Unit testing is the process of testing the smallest testable parts of an application, called "units" (functions, methods, classes), individually and independently for proper operation.

Deep Dive:

• Isolation: The key is isolation. A unit test should strictly test only the unit logic, mocking any external dependencies (Databases, APIs).
• Automation: Unit tests are almost always automated using frameworks like JUnit (Java), PyTest (Python), or Jest (JS).
• Cost: Bugs found here are the cheapest to fix because the code is fresh in the developer's mind.

Key Concepts: Drivers and Stubs (The Simulators) When Component A depends on Component B, but Component B isn't built yet, how do we test A? We cheat.

• Stub (A dummy "Called" function):
• Simulation of a lower-level module.
• Scenario: You are building the "Login" page (Top), but the "Database" (Bottom) isn't ready. You create a Stub that just returns "True" when you send a password, pretending to be the database.

• Driver (A dummy "Calling" function):
• Simulation of a higher-level module.
• Scenario: You are building the "Encryption" function (Bottom), but the "UI" (Top) isn't ready. You write a script (Driver) to send data to your function and print the result.

---

2. Integration Testing

Definition: A level of software testing where individual units are combined and tested as a group. The purpose is to expose faults in the interaction between integrated units.

The Challenge: "Everything works fine in isolation, but breaks when put together." (Interface errors).

Approaches (Strategies):

A. Big Bang Integration

• Concept: Develop all modules first. Then assemble them all at once and test.
• Analogy: Building a car by throwing all 5,000 parts into a pile and hoping it starts.
• Cons: Very risky. If it fails, debugging is a nightmare because you don't know which connection failed.

B. Incremental Integration (Better)

Adding modules one by one.

1. Top-Down Integration:

• Start from the UI/Main module and go down.
• Requires: Stubs to simulate missing lower layers.
• Pro: User sees a working prototype early.
• Con: Critical low-level logic is tested last.

2. Bottom-Up Integration:

• Start from the utility/database modules and go up.
• Requires: Drivers to trigger the lower layers.
• Pro: Core logic is solid.
• Con: User doesn't see the UI until the end.

3. Sandwich (Hybrid) Integration:

• Testing Top and Bottom layers simultaneously and meeting in the middle.
• Best of both worlds but complex to coordinate.