I decided to write this article after watching the last screencast made by Errichto. To be more precise when he started making stress testing to find counter-test you can check that here. Errichto has a full video called How to test your solution in Competitive Programming, on Linux? I highly recommend you to check it, basically this article is the same but I am extending it to stress test solutions with multiple answers using a written checker, so let’s jump in.

## Introduction

You can use stress testing in competitive programming to test your solution against many randomly generated tests in order to find a “small” test case that your solution produces wrong answer for this case, and hopefully this can help you to find the bug in your code of the mistake in your approach and eventually helping you solve the problem.

## Before starting

I think before starting with stress testing it would be good to have some knowledge about how problems are prepared, and how the process goes on, I will briefly talk about this and the purpose of every program you should write, I think this might help you understand whats coming next.

• Generator: It’s a program you should write to generate your test cases, for most problems it’s almost impossible to write tests manually, as the constraints might be very high (like an array on $$10^5$$ numbers) That’s where generators come to the rescue.

• Validator: It’s a program you should write to validate whether your generated tests are correct, for example if your input is a single prime number $$p$$ such that $$2\le p \le 10^6$$ then the validator must check than $$p$$ is in the given range, also it must check that $$p$$ is a prime number.

• Solution(s): Every problem must have different solutions to handle different complexities and to ensure that wrong solutions will fail the tests(like using greedy solution in dp problem), one of this solutions will be the main correct solution.

• Checker: It’s a program you should write to check if the solution is correct, some problems might have only one correct answer (like the following problem: count the number of prime numbers between $$a$$ and $$b$$) or multiple correct answers (like the following problem: print any prime number between $$a$$ and $$b$$).

All these programs work together in the following order, first the generator generates test cases, the validator receives these test cases and validates them, if the tests meet the constraints and the test is valid then the solution receives these tests and runs them, producing output files, finally the checker checks these output files and gives the final verdict. Simple isn’t it? (Remember to add image).

## What do you need to run Stress Tests?

To run stress tests you should have the code to test (the code giving WA), also you should write brute force solution, this solution usually is very slow but you are 100% sure it gives the right solution, in addition you need to write the tests generator to generate tests, you will need a checker if the problem can have multiple correct answers, but if the answer is unique we can just use diff function in Linux Operating system. We usually skip the validator, if we are sure our tests are correct.

## Example Problem

Let’s take this problem as an example. You probably know it, it’s Watermelon from Codeforces Beta Round #4 the problem says you are given a watermelon of weight $$w$$ and you should divide it into two parts of even weight and it’s not obligatory that the parts are equal. Let’s say you have written this code:

After submitting the code you get the verdict of WA on test 5, the brute force solution for this problem will be something like this:

Also the generator will look like this:

## Putting things together (bad implementation)

When I started doing stress testing I was using this bad implementation, instead of writing different programs and making them work together, I used to write these programs as Functions in the same code, and keep calling this functions, for the previous problem I would have written this kind of code:

After running this code you will pass some tests, eventually you will find the WA test, and you will get something like this:

Found the WA test
W = 2


I don’t recommend using this implementation for many reasons, first of all it’s really messy and hard to maintain, also in some harder problems you might have to use some global arrays or data structures for both the brute force and the tested solution and things might get out of control, the solution for that is to use a bash script to run each code individually. In the next section we will see how to efficiently implement this.

## Putting things together (good implementation)

A Bash script is a plain text file with the extension .sh which contains a series of commands. These commands are a mixture of commands we would normally type on the command line. When you run the script these commands will do the same thing as if you type them on the command line. In our previous problem we will have to run different programs each receiving some arguments or input from different files, and printing output to other files. Similar to the process we mentioned before, first we run the generator file, in our implementation the generator will receive seed as an argument passed from the script and print the generated test to file input_file. Both the tested solution and the brute force solution will get this file as an input and print the output to files myAnswer and correctAnswer respectively. As this problem is a one output problem then no need to use a checker, instead the diff function will check if the files match.

The script file will look like:

After running the script using bash script.sh you will get the following output:

WA on the following test:
2
YES
NO


Please note that the -Z after diff in line 9 means ignore white space at line end while comparing the files, please be careful that the online judge you are using ignores them too, at some sites like UVA one white space will cause you WA or PE. You can read more about other arguments with the function here.

## Use checker

In some problems more than one answer is accepted so you can’t use the diff function, Let’s take this problem as an example. In this problem You’re given an array $$a$$ of length $$2n$$. You have to find if it’s possible to reorder it in such way so that the sum of the first $$n$$ elements isn’t equal to the sum of the last $$n$$ elements. Now I have chosen one solution that fails on test 32 to stress test it, I have chosen this solution randomly so I am sorry if this was your solution. The code is:

Let’s start by writing the brute force solution:

And the generator:

The checker must check more than one thing, if there is a solution of no solution, and if there is a solution then it must be valid, by valid I mean that the sum of the first $$n$$ elements isn’t equal to the sum of the last $$n$$ elements. Also the printed array must be a valid permutation of the input array. Let’s see how the checker code will look like:

Finally the bash script will be:

Here the script will keep running until the returned value from the checker is equal to $$0$$ any nonzero value will make the script stop, this even includes compilition error while compiling the programs, to find the test case, your WA and the correct answer you can use cat command:

cat input_file


After running the script, the code will pass some tests eventually failing with this:

WA on the following test:
1
10 9
-1
9 10
Checker message:
Brute force found a solution, but the code didn't find


This is a small test case and you can easily find that the bug in your code is in line 17 when $$sum2$$ is an odd number. Figure 1: The testing process flow

## When to use Stress Testing?

Stress testing is a very powerful tool to find bugs in your code or mistakes in your idea, basically by finding a small test case that your code fails on then you can know what are you doing wrong, I used it to solve many problems, the most important one for me was this problem from ACM-ACPC Regional contest 2016. During the official contest I got stuck with WAs all the time, although I tried many other tests but still couldn’t find the bug, I think the reason for that is when you try extra tests by hand then those tests are not completely random, because you are writing them, and as a human you can’t be that random. However stress testing helps you overcome that issue. So make sure to use it every time you got stuck for long time with a problem without finding that WA test.

## Conclusion

In this article we started by defining stress testing, then briefly explained what a generator, validator and a checker mean and shown how these programs combine and work alongside with the problem solutions, next up we shown the need of a special solution called the brute force solution, then we presented an example problem and shown how to stress test it in a bad implemented way, improved the implementation using bash scripts, and moved on to show how to use checker with problems having multiple correct answers, finally we have shown when to use stress testing.