Documentation Home
The MySQL Test Framework, Version 1.0
Download this Manual
PDF (US Ltr) - 443.8Kb
PDF (A4) - 445.5Kb
EPUB - 101.9Kb

The MySQL Test Framework, Version 1.0  /  MySQL Test Framework Components

Chapter 2 MySQL Test Framework Components

The MySQL test framework consists of programs that run tests, and directories and files used by those programs.

Test Framework Programs

The MySQL test framework uses several programs:

  • The Perl script is the main application used to run the test suite. It invokes mysqltest to run individual test cases. (Prior to MySQL 4.1, a similar shell script, mysql-test-run, can be used instead.)

  • mysqltest runs test cases. A version named mysqltest_embedded is similar but is built with support for the libmysqld embedded server.

  • The mysql_client_test program is used for testing aspects of the MySQL client API that cannot be tested using mysqltest and its test language. mysql_client_test_embedded is similar but used for testing the embedded server.

  • The Perl script performs stress-testing of the MySQL server. (MySQL 5.0 and up only)

  • A unit-testing facility is provided so that individual unit test programs can be created for storage engines and plugins. (MySQL 5.1 and up only)

Test suite programs can be found in these locations:

  • For a source distribution, mysqltest is in the client directory. For a binary distribution, it is in the MySQL bin directory.

  • For a source distribution, mysql_client_test is in the tests directory. For a binary distribution, it is in the MySQL bin directory.

  • The other programs are located in the mysql-test directory. For a source distribution, mysql-test is found under the source tree root. For a binary distribution, the location of mysql-test depends on the layout used for the distribution format.

Test Framework Directories and Files

The test suite is located in the mysql-test directory, which contains the following components:

  • The and programs that are used for running tests.

  • The t directory contains test case input files. A test case file might also have option files associated with it.

    • A file name of the form test_name.test is a test case file for a test named test_name. For example, subquery.test is the test case file for the test named subquery.

    • A file name of the form test_name-master.opt provides options to associate with the named test case. restarts the server with the options given in the file if the options are different from those required for the currently running server.

      Note that the -master.opt file is used for the main server of a test, even if no replication is involved.

    • A file name of the form test_name-slave.opt provides slave options.

    • A file name of the form test_name-im.opt provides Instance Manager options.

    • The disabled.def file contains information about deferred/disabled tests. When a test is failing because of a bug in the server and you want it to be ignored by, list the test in this file.

      The format of a line in the disabled.def file looks like this, where fields are separated by one or more spaces (Tab characters are not allowed):

      test_name : BUG#nnnnn YYYY-MM-DD disabler comment


      rpl_row_blob_innodb : BUG#18980 2006-04-10 kent  Test fails randomly

      test_name is the test case name. BUG#nnnnn indicates the bug related to the test that causes it to fail (and thus requires it to be disabled). disabler is the name of the person that disabled the test. comment normally provides a reason why the test was disabled.

      A comment line can be written in the file by beginning the line with a # character.

  • The r directory contains test case result files:

    • A file name of the form test_name.result is the expected result for the named test case. A file r/test_name.result is the output that corresponds to the input in the test case file t/test_name.test.

    • A file name of the form test_name.reject contains output for the named test case if the test fails.

    For a test case that succeeds, the .result file represents both the expected and actual result. For a test case that fails, the .result file represents the expected result, and the .reject file represents the actual result.

    If a .reject file is created because a test fails, removes the file later the next time the test succeeds.

  • The include directory contains files that are included by test case files using the source command. These include files encapsulate operations of varying complexity into a single file so that you can perform the operations in a single step. See Section 4.11, “Using Include Files to Simplify Test Cases”.

  • The lib directory contains library files used by, and database initialization SQL code.

  • The std_data directory contains data files used by some of the tests.

  • The var directory is used during test runs for various kinds of files: log files, temporary files, trace files, Unix socket files for the servers started during the tests, and so forth. This directory cannot be shared by simultaneous test runs.

Unit test-related files are located in the unittest directory. Additional files specific to storage engines and plugins may be present under the subdirectories of the storage or plugin directories.

Test Execution and Evaluation

There are a number of targets in the top-level Makefile that can be used to run sets of tests. make test runs all the tests. Other targets run subsets of the tests, or run tests with specific options for the test programs. Have a look at the Makefile to see what targets are available.

A test case is a single file. The case might contain multiple individual test commands. If any individual command fails, the entire test case is considered to fail. Note that fail means does not produce the expected result. It does not necessarily mean executes without error, because some tests are written precisely to verify that an illegal statement does in fact produce an error. In such an instance, if the statement executes successfully without producing the expected error, that is considered failure of the test.

Test case output (the test result) consists of:

  • Input SQL statements and their output. Each statement is written to the result followed by its output. Columns in output resulting from SQL statements are separated by tab characters.

  • The result from mysqltest commands such as echo and exec. The commands themselves are not echoed to the result, only their output.

The disable_query_log and enable_query_log commands control logging of input SQL statements. The disable_result_log and enable_result_log commands control logging of SQL statement results, and warning or error messages resulting from those statements.

mysqltest reads a test case file from its standard input by default. The --test-file or -x option can be given to name a test case file explicitly.

mysqltest writes test case output to the standard output by default. The --result-file or -R option can be used to indicate the location of the result file. That option, together with the --record option, determine how mysqltest treats the test actual and expected results for a test case:

  • If the test produces no results, mysqltest exits with an error message to that effect.

  • Otherwise, if --result-file is not given, mysqltest sends test results to the standard output.

  • With --result-file but not --record, mysqltest reads the expected results from the given file and compares them with the actual results. If the results do not match, mysqltest writes a .reject file in the same directory as the result file and exits with an error.

  • With both --result-file and --record, mysqltest updates the given file by writing the actual test results to it.

mysqltest itself knows nothing of the t and r directories under the mysql-test directory. The use of files in those directories is a convention that is used by, which invokes mysqltest with the appropriate options for each test case to tell mysqltest where to read input and write output.

Download this Manual
PDF (US Ltr) - 443.8Kb
PDF (A4) - 445.5Kb
EPUB - 101.9Kb