Every programmers knows too well that it is extremely unlikely that a rather complex program is correct at the first cut. It is too easy to make errors when programming.
Some errors are caught as syntax errors or signaled as warnings by the compiler, but still way too many errors slip under the programmer sight.
In addition, when a correct program is changed there is the concrete risk of introducing an error is a feature different from the one that is meant to change. Such defects, are named “regressions”, as the quality of that part of the software is worsened instead of being improved or of being kept constant.
Therefore some procedures are needed both for detecting and correcting defects in newly developed software, and for detecting and correcting regressions.
The two most important procedures to detect defects are testing and code revision. The two most important procedures to correct defects are logging and debugging. Here we’ll say something about testing.
To test a piece of software means to run it with sample input data and to watch if its output data is what is actually expected. Notice that, as the possible combinations of input data is virtually infinite, there is little hope of ensure (i.e. mathematically prove) that a piece of software is correct. The purpose of testing is reducing the probability that a defect of the software will cause a failure (or an inconvenience) in operation. This is performed discovering and correcting the defects that most probably will be detected also by the end users.
Therefore, it is pointless to use unlikely input data, as rarely the end users will. You should give to the program under test a sample of rather probable input data. Of course users sometimes input some weird data, and therefore those are to be taken into account. The best thing to do is to prevent weird data to pass the input validation stage and to enter the computation stage, and so when testing the computation stage such data may be ignored.