MySQL 9.1.0
Source Code Documentation
|
The test code we just wrote contains no checks of the result.
The test will report a failure for one of two reasons:
Note that these are the reasons why mysqltest would fail; if the test is run from mysql-test-run.pl the test may fail for additional reasons.
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 Dealing with Output That Varies Per Test Run.