- 4 Writing Test Cases
- 4.1 Writing a Test Case: Quick Start
- 4.2 Test Case Coding Guidelines
- 4.3 Sample Test Case
- 4.4 Cleaning Up from a Previous Test Run
- 4.5 Generating a Test Case Result File
- 4.6 Checking for Expected Errors
- 4.7 Controlling the Information Produced by a Test Case
- 4.8 Dealing with Output That Varies Per Test Run
- 4.9 Passing Options from mysql-test-run.pl to mysqld or mysqltest
- 4.10 Specifying Test Case-Specific Server Options
- 4.11 Using Include Files to Simplify Test Cases
- 4.12 Controlling the Binary Log Format Used for Tests
- 4.13 Writing Replication Tests
- 4.14 Thread Synchronization in Test Cases
- 4.15 Other Tips for Writing Test Cases
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-testshell>./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 4.8, “Dealing with Output That Varies Per Test Run”.
