Exception and error testing

Exception and error testing (error-handling testing) checks that the software detects abnormal conditions and handles them correctly: it should report a clear message, protect data, and either recover or fail safely, instead of crashing or producing wrong results. A well-designed program anticipates errors and has error-handling paths, and these paths must be tested just like normal paths.

What is tested

• Invalid inputs: wrong type, out-of-range values, empty fields, very long strings.
• Exceptions thrown by code: divide by zero, null reference, array index out of bounds, file not found, overflow.
• External failures: database or network down, disk full, time-out, hardware failure.
• Recovery: after the error, the system returns to a consistent state (transactions rolled back, resources released).

Typical error-handling faults (Pressman)

1. The error description is unintelligible to the user.
2. The error noted does not match the error actually encountered.
3. The error condition causes system intervention (crash) before error handling runs.
4. Exception-condition processing is incorrect.
5. The error description does not give enough information to find the cause.

Techniques

• Use invalid equivalence classes and boundary values as test inputs.
• Fault injection: deliberately cause failures (e.g. disconnect the database) to see how the system reacts.
• White-box coverage of every catch/error branch.
• Recovery testing: force the software to fail and check that it recovers within the required time.
• Unit-test frameworks can assert that an exception is thrown, e.g. JUnit assertThrows(ArithmeticException.class, () -> divide(5, 0)).

Example

In a bank transfer feature:

Exception and error testing improves robustness and reliability, since many real failures come from conditions that the normal tests never exercise.