During a USACO contest you are shown one sample test per problem. Your program is then graded on at least ten hidden test groups. Everything between passing that single sample and scoring points is closed by tests you write yourself. This is the sharpest difference between USACO and the practice judges most students train on — and it is why testing discipline, not algorithm knowledge, decides a surprising number of scores.
The sample test is a format check, not a correctness check
Students treat the sample as a verdict. It is not. One small, well-behaved input can only confirm two things: that your program reads and writes in the shape the problem asks for, and that your logic is not catastrophically wrong on an easy case. Both are useful. Neither is evidence that you will score.
Compare this to a rated practice judge, where a failed submission often tells you the test number, sometimes the input, and always the fact that something is wrong within minutes. USACO's grader also marks each judging case pass or fail as soon as you submit, and you can resubmit inside your window; what it never shows you is the failing input or the expected output, so you learn that something broke without learning what.
Here is what one sample can and cannot catch. This table is the argument for everything that follows.
| Bug class | Caught by the sample? | What actually catches it |
|---|---|---|
| Wrong output format (extra line, wrong order, missing space) | Usually yes | The sample — this is its real job |
| Completely wrong approach | Often yes | The sample, plus a hand-computed second case |
| Too slow for large inputs | Never — the sample is tiny | A generated maximum-size input, timed locally |
| Fails at the minimum (single element, empty answer) | Almost never | A deliberate minimum-input test you write |
| Number range overflow | Almost never | An extreme-values test built from the stated constraints |
| Degenerate input (all values equal, everything already sorted) | Rarely | A degenerate case you construct by hand |
| Subtle logic bug on ordinary input | No — this is the dangerous one | Stress testing against a brute force |
The five cases to write before you submit anything
This takes five to eight minutes per problem once it is a habit, and it is the highest-return five minutes in the contest. Write these before you submit, not after you get a disappointing score.
- 1. The minimum. Whatever the smallest legal input is — one cow, one day, one node, an empty answer — feed it in. Loops written for the general case routinely index past the end or print a stray separator here. Read the constraint line and use the literal lower bound it gives you.
- 2. The maximum, timed. Generate an input at the largest size the constraints permit and run it with a stopwatch. Do not estimate; measure. This is also where the language asymmetry bites: the time limit is 2 seconds for C++ and 4 seconds for Java and Python, so a Python solution that takes 6 seconds locally is not close — it is out.
- 3. The degenerate case. All values identical. Everything already in sorted order. Everything in reverse order. A graph that is one long chain, or one star. These inputs break comparison logic, tie-breaking rules and early-exit conditions more often than random data ever will.
- 4. The range extremes. Take the largest and smallest values the constraints allow, then ask what your program computes when you add or multiply several of them together. If the answer can exceed what a 32-bit integer holds, use a 64-bit type. In the contest write-ups our coaching team reviews, this single check is behind a lot of “most groups passed, a few failed” scores.
- 5. One medium case you solved by hand. Six to ten elements, worked out on paper before you run the program. This is the only test in the list that verifies your understanding of the problem rather than the robustness of your code. If your program disagrees with your paper, one of the two has misread the statement — and finding out which one, now, is worth twenty minutes.
Keep these five in a scratch file per problem rather than retyping them. During a four-to-five-hour block you will run them more than once, especially after you rewrite a slow solution into a fast one.
The stress-test loop that few of our Bronze and Silver students have ever run
The five cases above catch structural bugs. They do not catch the worst category: a solution that is subtly wrong on ordinary input. For that you need the technique that separates students who plateau from students who promote.
The idea is simple. You already have a brute force — the obviously-correct, too-slow program you wrote first to bank the small test groups. You also have your fast solution. On small inputs, both must agree. So generate small random inputs by the thousand and compare them.
Three details make the difference between a loop that finds bugs and one that wastes an hour.
- Keep the random inputs tiny. Values in a range of one to five, sizes of one to eight. Small inputs are where bugs hide and where a human can still read the failing case and see what went wrong. Large random inputs mostly prove nothing and take longer.
- Randomise the shape, not just the numbers. Vary the size on every iteration, and bias your generator towards repeats and ties. A generator that only ever emits distinct values will never find your tie-breaking bug.
- Stop at the first mismatch and print the input. The whole value of the technique is that it hands you a concrete failing case. A loop that reports only “1 of 2,000 failed” without showing you the input has thrown away the prize.
To be explicit about the rules, since testing tooling is exactly where students ask: you write the generator and the brute force yourself, as part of your own solution. USACO requires that the work be entirely your own and prohibits generative-AI assistance such as Copilot or ChatGPT; cheating carries a permanent ban from all USACO activities. Our note on academic integrity spells out where the line sits.
Build the harness before the season, not during a contest
None of this works if contest day is the first time you try it. Fumbling a generator together while a five-hour clock runs is how students lose forty minutes and their composure at once. The fix is a short off-season rehearsal, done once, then reused every contest.
| When | What to build | Done when |
|---|---|---|
| Off-season, one evening | A reusable generator skeleton and a compare-loop script in whichever language you contest in | You can point it at two programs and get a verdict without looking anything up |
| Off-season, same evening | A timing command you trust for measuring your maximum-size run | You know your own machine’s speed on a simple loop, so local timings mean something to you |
| Every practice session | Run the five-case checklist before you check any editorial | It feels like part of solving, not an extra chore |
| One full timed rehearsal | A past contest, four to five hours, using the harness under real conditions | You used it at least once without thinking about how |
| Contest day | Nothing new. Only the tests, not the tooling | — |
Previous contests are the right material for that rehearsal, because they are the only source that matches the real format: the long block, roughly three problems, the single visible sample, group-based scoring. Our past-contest resources collect the sets we use for exactly this, and the division guide notes which techniques each division expects you to have ready.
What this is actually worth
Testing discipline is unglamorous, and students resist it because it feels like admin rather than progress. So it is worth being concrete about the payoff, in the language of the scoring system.
Recall that a problem is graded on at least ten groups, each worth roughly 33 points. The classic profile of an untested solution is most groups passing and two or three failing — a loss of around 60 to 100 points on that problem. Repeat that across two problems in a paper and you have given away a chunk of the contest to bugs your own five-minute checklist would have caught. Under a cutoff sitting somewhere in the region recent seasons have seen, that margin is frequently the whole decision. Cutoffs are set per contest and move, so check the current picture and confirm on usaco.org rather than planning against a number.
Across our own last three seasons of coaching, our de-identified tally records 18 Platinum, 70 Gold and 100 Silver promotions among students we worked with — our own count, not a USACO statistic, and individual results vary widely. When a student stalls in the same division for two seasons, the single change our coaching team most often asks for is not a new algorithm. It is a stress-test harness and the habit of running the five cases before submitting. That is our team's judgement from watching contest write-ups, not a claim about what any individual result will be.
How many sample tests does a USACO problem show?
One per problem during the contest. Grading uses at least ten hidden test groups, so passing the sample proves very little.
What is stress testing?
Running a random small-input generator against both a slow correct solution and your fast one, then comparing outputs until they differ.
What time limits should I test against?
2 seconds for C++ and 4 seconds for Java and Python. Time your maximum-size input locally rather than estimating.
Is writing a test generator allowed?
Yes, if you write it yourself. USACO requires independent work and prohibits generative-AI assistance; cheating carries a permanent ban.
This is an independent guide operated by Hanlin Education for China-based international-school students. It is not affiliated with, endorsed by, or sponsored by USACO (the USA Computing Olympiad). Contest format, time limits, scoring, rules and dates are set by USACO and may change — always confirm current details on usaco.org, where registration and participation take place. Cohort figures are our own de-identified tally, not a USACO statistic, and individual results vary. Any factual error brought to our attention is corrected within 7 working days.