In the world of software testing, one of the most well-known problems used to teach test case design is the Classic Triangle Testing Problem, also known as Myer’s Triangle Problem. This problem is not just a practical exercise—it’s a foundational concept for learning equivalence partitioning, boundary value analysis, and input validation.
Let’s walk through this problem, understand its importance, and then explore a set of test cases to ensure a program that solves this problem behaves correctly under various input scenarios.
Problem Statement
The Triangle Program reads three integer values that represent the lengths of the sides of a triangle. Based on the input values, the program determines and prints whether the triangle is:
- Equilateral – All three sides are equal.
- Isosceles – Two sides are equal.
- Scalene – All three sides are different.
However, as simple as this might sound, various types of input values—including invalid, missing, or malformed data—can cause issues. Therefore, designing robust test cases becomes essential to validate the program’s correctness and reliability.
Assumptions Made for This Program
To build realistic and comprehensive test cases, the following assumptions were made:
- The program accepts any type of input (characters, alphabets, null, symbols, etc.), but only performs the classification if all inputs are valid integers greater than zero.
- An exception handler is implemented to catch invalid inputs and provide user-friendly error messages.
- The triangle side values have no upper limit—they can be any positive integer.
- Exponential values (e.g., scientific notation) are not allowed.
- Inputs must consist of exactly three values.
- If any input is missing, empty, or of the wrong type, the program throws a descriptive error.
Test Case Table
Here’s a carefully curated set of test cases that validate both the functionality and robustness of the Triangle Classification Program:
| S.N | Requirement Tested | Inputs | Expected Results |
|---|---|---|---|
| 1 | No inputs | Null | Error: No values found; 3 integer values must be given |
| 2 | Single value input | 25 | Error: Missing values |
| 3 | Two values input | 25, 15 | Error: Missing values |
| 4 | Fraction input | 10/5, 15/2, 2 | Error: Only integers input accepted |
| 5 | Negative integers | -5, -6, 8 | Error: Positive integers only |
| 6 | Input with spaces only | (empty, empty, empty) | Error: Missing values |
| 7 | Character input | !, $, % | Error: Only integers input accepted |
| 8 | Alphabet input | a, v, e | Error: Only integers input accepted |
| 9 | Valid Scalene Triangle | 7, 45, 36 | This is a Scalene Triangle |
| 10 | Valid Equilateral Triangle | 10, 10, 10 | This is an Equilateral Triangle |
| 11 | Valid Isosceles Triangle | 35, 35, 10 | This is an Isosceles Triangle |
| 12 | One side is zero | 35, 10, 0 | Error: Values must be greater than 0 (>0) |
| 13 | Two sides are zero | 0, 0, 12 | Error: Values must be greater than 0 (>0) |
| 14 | All sides are zero | 0, 0, 0 | Error: Values must be greater than 0 (>0) |
| 15 | Exponential values | 2e2, 5e3, 5.35e2 | Error: Exponential values not allowed |
The Triangle Problem teaches a crucial lesson in input validation and classification logic. From a software quality perspective, here’s what makes it valuable:
- Input handling: The program must distinguish between valid and invalid input, rejecting anything that does not conform to its expectations.
- Boundary conditions: Testing with
0, negative numbers, or very large values ensures that the program respects constraints. - Classification logic: Understanding how to compare side lengths correctly to classify triangle types is a core programming logic exercise.
- Robust error messages: Ensuring users are properly guided when they provide incorrect input enhances user experience.
This classic problem may appear simple, but it reflects a real-world challenge: validating inputs and ensuring accurate processing under varied scenarios. As developers and testers, building strong, comprehensive test cases like the ones above ensures that even the most basic programs can stand up to unexpected inputs and edge cases.
This example is also a great starting point for introducing unit testing, black-box testing, and defensive programming techniques to beginner developers.
