Cover your ground with test cases
You should include test cases in your question so that someone can check if their program is correct (with high probability) by whether it gets all the test cases right. These test cases should give inputs and outputs.
(Of course, this is moot for challenges with no input and a fixed output, like kolmogorov-complexity.)
Your test cases should cover the conceptual span of possible inputs, so that if a program gets your test cases right, it is likely to behave correctly on all inputs. Does your spec require negative numbers to be handled? Test them! Is the empty string a valid input? Include it! Can the list length go up to 255? Include a length-255 list!
Particularly important are edge cases that could be pitfalls for slightly-wrong algorithms. If there's a heuristic algorithm that gets most inputs right, but not all, emphasize these "interesting" inputs in the test cases. Conversely, look at your test cases and see if there's an unintentional pattern so you can include additional ones that break it.
However, if your challenge is such that there really only one "type" of input, and anything that gets one interesting input right surely gets all of them right, then just one of two test cases is fine.