The test code we just wrote contains no checks of the result.
The test will report a failure for one of two reasons:
An individual SQL statement fails with an error
The overall test case result does not match what was
expected
In the first case, mysqltest aborts with an
error. The second case requires that we have a record of the
expected result so that it can be compared with the actual
result. To generate a file that contains the test result, run
the test with the --record option, like this:
shell>
cd mysql-test
shell>
./mysql-test-run.pl --record foo
Running the test as shown creates a result file named
mysql-test/r/foo.result that has this
content:
DROP TABLE IF EXISTS t1,t2;
CREATE TABLE t1 (
Period SMALLINT(4) UNSIGNED ZEROFILL DEFAULT '0000' NOT NULL,
Varor_period SMALLINT(4) UNSIGNED DEFAULT '0' NOT NULL
);
CREATE TABLE t2 (Period SMALLINT);
INSERT INTO t1 VALUES (9410,9412);
INSERT INTO t2 VALUES (9410),(9411),(9412),(9413);
SELECT period FROM t1;
period
9410
SELECT * FROM t1;
Period Varor_period
9410 9412
SELECT t1.* FROM t1;
Period Varor_period
9410 9412
SELECT * FROM t1 INNER JOIN t2 USING (Period);
Period Varor_period
9410 9412
DROP TABLE t1, t2;
ok
If we look at this result file, it contains the statements in
the foo.test file together with the output
from the SELECT statements. The output for
each statement includes a row of column headings followed by
data rows. Rows have columns separated by Tab characters.
At this point, you should inspect the result file and determine
whether its contents are as expected. If so, let it be part of
your test case. If the result is not as expected, you have found
a problem, either with the server or the test. Determine the
cause of the problem and fix it. For example, the test might
produce output that varies from run to run. To deal with this,
you can postprocess the output before the comparison occurs. See
Section 3.3.8, âDealing with Output That Varies Per Test Runâ.