Unit Testing 2

Systematic Approaches: Required to design effective test suites where each case targets different faults.
Test Strategy: Addresses which test types to deploy and how much effort to devote to each.
Defect Clustering: Historically, a few modules (error-prone modules) contain the majority of defects found in a system.
Past Bug Data: Planning test effort should be guided by past detection data, which often shows that reviews and unit tests catch the highest percentage of bugs before release.

Definition: Testing individual methods, modules, or classes in isolation after they compile successfully.
Rationale: Reduces debugging effort substantially; without it, errors become difficult to track down and debugging costs increase.
Support Structures:
- Driver: Simulates the behavior of a calling function and supplies data to the unit being tested.
- Stub: Simulates the behavior of a function called by the unit that has not yet been written.
Activities: Unit testing is primarily considered a verification activity.

Black-Box (Functional) Testing: Designing cases using only the functional specification without knowledge of internal code.
White-Box (Structural) Testing: Requires knowledge of the internal code structure.
Grey-Box Testing: Combines elements of both; testers have limited internal knowledge to design intelligent cases while focusing on the user view.

Derived from Use Cases by identifying the basic flow and all alternative flows.
Each scenario leads to one or more test cases defined by conditions, inputs, and expected results.

Goal: Partition the input domain into classes where the program is expected to behave similarly for every value in that class.
Guidelines:
- Range: One valid and two invalid classes (e.g., for range 1–100, classes are <1, 1–100, and >100).
- Set: One valid and one invalid class.
- Boolean: One valid and one invalid class.
Types of ECP Testing:
- Weak: Uses one representative from each valid class.
- Strong: Covers all possible combinations of valid classes.
- Robust: Includes invalid equivalence classes to test error handling.

Range Name	Condition (Days)	Interest Rate	Class Type
Invalid Low	$days \le 0$	N/A (Error)	Invalid
Bracket 1	$1 \le days \le 15$	3%	Valid
Bracket 2	$16 \le days \le 180$	4%	Valid
Bracket 3	$181 \le days \le 365$	6%	Valid
Bracket 4	$366 \le days < 1095$	7%	Valid
Bracket 5	$days \ge 1095$	8%	Valid
#### Exercise 3

Equivalence Class	Type	Logic	Example Value
Class 1	Valid	$0 \le L1 \le 20$	"NITC_Calicut" (Length 12)
Class 2	Invalid	$L1 > 20$	"ThisStringIsWayTooLongForThisInput"
Equivalence Class	Type	Logic	Example Value
Class 3	Valid	$0 \le L2 \le 5$	"Lab" (Length 3)
Class 4	Invalid	$L2 > 5$	"Calicut" (Length 7)
Equivalence Class	Type	Logic
Class 5	Valid	$s2$ exists within $s1$ (Match found).
Class 6	Valid	$s2$ does not exist within $s1$ (No match).
Class 7	Invalid/Edge	$L2 > L1$ (A longer string cannot be a substring of a shorter one).
#### C. Boundary Value Analysis (BVA)

Rationale: Typical programming errors (like using < instead of <=) often occur at the boundaries of equivalence classes.
Basic BVT: Selects values at the minimum, just above minimum, nominal, just below maximum, and maximum for each input.
Robust BVT: Adds values just outside the boundaries (below minimum and above maximum).
Efficiency Formulas (for $n$ independent inputs):
- Basic BVT: Requires $4n + 1$ test cases.
- Robust BVT: Requires $6n + 1$ test cases.

Testing values known to expose bugs based on the tester's experience, such as division by zero, null pointers, or empty data structures.
Unit Testing fundamentals
Types of Testing
Scenario-based Testing
Equivalence Class Partition
Boundary Value Analysis
Special Value Testing