How to know testcases where code fails?

In Competitive Programming, it’s quite often to write code that works on the given sample test cases but on submitting its end up with a WA(Wrong answer) verdict. This is where things get frustrating and not know on which test case the solution fails. In such situations there are a few things that a programmer can do:

1. Check manually for corner cases
2. Stress Testing

Checking for Corner Cases:

In some problem-statement, it has corner test cases where the programmer needs to add/edit some lines of code to make sure the program works fine for those cases as well. For example, in a problem where it needs to find the Minimum Positive Integer in an array and if a solution something like this:

int mn = arr[0]
for i : 1 -> arr_size:
    if (arr[i] < mn)
          mn = arr[i]
print mn

Explanation:
The above logic would not give an AC(Accepted) verdict and it is easy to figure out the problem here. One of the test cases where this code will fail is when the array is arr[] = {2, -1, 3, 4, 5}. The above algorithm Output is -1 But the correct Output is 2.
For finding the minimum positive integer, it needs to edit the code to make sure negative integers must not be included.

Stress Testing:

Stress Testing is a code testing technique that determines the robustness of code by testing beyond the limits of normal operation. Suppose a problem which has a naive solution(slow) and an optimal solution(fast) gets a TLE (Time Limit Exceeded) verdict on submitting the brute force solution, so come up with the optimal solution but on submitting it we get WA on some or all test cases.

Now the first thing to do here would be to think of some test cases where the solution may not work and check the solution on them. If unable to think of the test cases then there is one more way and that is stress testing. 

In stress testing, the idea is to generate random test cases and check the output of the brute force solution and the optimal solution. Though the brute force solution is slow still it’s correct while the optimal solution is faster but it’s wrong in some test cases. This allows us to check if the optimal solution’s output of some test case is correct or not without manually checking, it can simply check if the output of Naive Solution agrees with the Optimal Solution’s output. The checking is done automatically and also the correctness of code on thousands depends on the complexity of the Naive Solution of test cases in seconds, so the probability of finding the test case where our code fails becomes way high.

So, perform the below steps to check the solution on random input by running an infinite loop:

1. Generate random input (click here to know how)
2. Store output of brute force and optimal solution
3. If the two outputs are (equal) then print correct
4. Else print the input and break the loop

If the loop runs for some time without breaking i.e., all the outputs are correct then either check for larger input or try submitting your solution.

Example:

Problem Statement: Given an array arr[] of N positive Integers, the task is to find the maximum pairwise product of elements in an array.

Input: arr[] = [2, 3, 4, 9, 4, 7]
Output: 63 
Explanation:
The maximum pairwise product of the array is 9 * 7 = 63.

Input: arr[] = [-20, -50, 1, 2]
Output: 1000
Explanation:
The maximum pairwise product of the array is (-20) * (-50) = 1000.

Below is the implementation of stress testing for the above problem:

Wrong Answer
4
-4 -3 -3 1 
Correct Output: 12
Wrong Output: -3

Explanation:
The Optimal Solution works fine for positive integers but fails on negative integers like shown in the output of the code. Through stress test it was figured out the problem with the code. To generate and test our code for larger input, generate larger integers for n and a[I].

Summary: Stress testing will surely help in debugging the code but first should try to think of test case where the code may not work because its less complex to check for some simple test cases and if that doesn’t help then proceed with the Stress Testing.