4493d40a-92aa-4162-9dfc-bfc4ec0996e6
/
polardbxengine
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
polardbxengine/mysql-test/mysql-test-run.dox

8407 lines
277 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

########## The MySQL Test Framework ##########
/**
@page PAGE_MYSQL_TEST_RUN The MySQL Test Framework
This manual describes the MySQL test framework, consisting of the
test driver and the test script language.
-----
<h3>Table of Contents</h3>
- @subpage PAGE_PREFACE
- @subpage PAGE_INTRODUCTION
- @subpage PAGE_MYSQLTEST_FRAMEWORK_COMPONENTS
- @subpage PAGE_RUNNING_TESTCASES
- @subpage PAGE_WRITING_TESTCASES
- @subpage PAGE_MYSQLTEST_PROGRAMS
- @subpage PAGE_MYSQLTEST_LANGUAGE_REFERENCE
- @subpage PAGE_UNIT_TESTS
- @subpage PAGE_PLUGINS
*/
###############################################################################
## Preface
/**
@page PAGE_PREFACE Preface
MySQL distributions include a set of test cases and programs for
running them. These tools constitute the MySQL test framework that
provides a means for verifying that MySQL Server and its client
programs operate according to expectations. The test cases consist
mostly of SQL statements, but can also use test language constructs
that control how to run tests and verify their results.
This manual describes the MySQL test framework. It describes the
programs used to run tests and the language used to write test
cases.
*/
###############################################################################
## Introduction to the MySQL Test Framework
/**
@page PAGE_INTRODUCTION Introduction to the MySQL Test Framework
MySQL distributions include a test suite: a set of test cases and
programs for running them. (If you find that the test suite is not
included in your distribution, look for a similar distribution with
<b>-test</b> in the name and install that as well.) These tools
constitute the MySQL test framework that provides a means for
verifying that MySQL Server and its client programs operate
according to expectations. The test cases consist mostly of SQL
statements, but can also use test language constructs that control
how to run tests and verify their results. Distributions also
provide facilities for running unit tests and creating new unit
tests.
This document describes the components of the MySQL test framework,
how the test programs work, and the language used for writing test
cases. It also provides a tutorial for developing test cases and
executing them.
The application that runs the test suite is named @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl". Its location is the
<b>mysql-test</b> directory, which is present both in source and
binary MySQL Server distributions.
On platforms other than Windows, @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl" is also available through the shortened name
<b>mtr</b> in the same directory, as either a symbolic link or a
copy.
The @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" application
starts MySQL servers, restarts them as necessary when a specific
test case needs different start arguments, and presents the test
result. For each test case, @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl" invokes the @ref PAGE_MYSQLTEST "mysqltest"
program (also referred to as the “test engine”) to read the test
case file, intepret the test language constructs, and send SQL
statements to the server.
Input for each test case is stored in a file, and the expected
result from running the test is stored in another file. The actual
result is compared to the expected result after running the test.
For a MySQL source distribution, @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl" is located in the <b>mysql-test</b> directory,
and @ref PAGE_MYSQLTEST "mysqltest" is located in the <b>client</b>
directory. The <b>mysql-test</b> and <b>client</b> directories
are located in the root directory of the distribution.
For a MySQL binary distribution, @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl" is located in the <b>mysql-test</b> directory,
and @ref PAGE_MYSQLTEST "mysqltest" is located in the same directory
where other client programs such as <b>mysql</b> or
<b>mysqladmin</b> are installed. The locations of the
<b>mysql-test</b> and other directories depend on the layout used
for the distribution format.
Within the <b>mysql-test</b> directory, test case input files and
result files are stored in the <b>t</b> and <b>r</b>
directories, respectively. The input and result files have the same
basename, which is the test name, but have extensions of
<b>.test</b> and <b>.result</b>, respectively. For example, for
a test named “decimal”, the input and result files are
<b>mysql-test/t/decimal.test</b> and <b>mysql-test/r/decimal.result</b>.
Each test file is referred to as one test case, but usually consists
of a sequence of related tests. An unexpected failure of a single
statement in a test case makes the test case fail.
There are several ways a test case can fail:
<ul>
<li>
The @ref PAGE_MYSQLTEST "mysqltest" test engine checks the result
codes from executing each SQL statement in the test input. If the
failure is unexpected, the test case fails.
</li>
<li>
A test case can fail if an error was expected but did not occur
(for example, if an SQL statement succeeded when it should have
failed).
</li>
<li>
The test case can fail by producing incorrect output. As a test
runs, it produces output (the results from <b>SELECT</b>,
<b>SHOW</b>, and other statements). This output is compared
to the expected result found in the <b>mysql-test/r</b> directory
(in a file with a <b>.result</b> suffix). If the expected and
actual results differ, the test case fails. The actual test result
is written to a file in the <b>mysql-test/var/log</b> directory
with a <b>.reject</b> suffix, and the difference between the
<b>.result</b> and <b>.reject</b> files is presented for
evaluation.
</li>
<li>
A test case will fail if the MySQL server dies unexpectedly during
the test. If this happens, the @ref PAGE_MYSQLTEST "mysqltest"
test client will usually also report a failure due to loosing the
connection.
</li>
<li>
Finally, the test case will fail if the error log written by the
MySQL server during the test includes warnings or errors which are
not filtered (suppressed). See @ref PAGE_SUPPRESSING_ERRORS_WARNINGS
for more about suppressing warnings.
</li>
</ul>
This method of checking test results puts some restrictions on how
test cases can be written. For example, the result cannot contain
information that varies from run to run, such as the current time.
However, if the information that varies is unimportant for test
evaluation, there are ways to instruct the test engine to replace
those fields in the output with fixed values.
Because the test cases consist mostly of SQL statements in a text
file, there is no direct support for test cases that are written in
C, Java, or other languages. Such tests are not within the scope of
this test framework. But the framework does support executing your
own scripts and initiating them with your own data. Also, a test
case can execute an external program, so in some respects the test
framework can be extended for uses other than testing SQL
statements. Finally, it is possible to embed small pieces of Perl
code within the test. This can sometimes be used to perform actions
or execute logic which is beyond the capabilities of the test
language or SQL.
*/
###############################################################################
## MySQL Test Framework Components
/**
@page PAGE_MYSQLTEST_FRAMEWORK_COMPONENTS MySQL Test Framework Components
<h3>Table of Contents</h3>
- @subpage PAGE_TEST_FRAMEWORK_SYSTEM_REQUIREMENTS
- @subpage PAGE_REPORT_BUGS
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:
<ul>
<li>
The @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" Perl script
is the main application used to run the test suite. It invokes
@ref PAGE_MYSQLTEST "mysqltest" to run individual test cases.
</li>
<li>
@ref PAGE_MYSQLTEST "mysqltest" runs test cases.
</li>
<li>
The @ref PAGE_MYSQL_CLIENT_TEST "mysql_client_test" program is
used for testing aspects of the MySQL client API that cannot be
tested using @ref PAGE_MYSQLTEST "mysqltest" and its test
language.
</li>
<li>
The @ref PAGE_MYSQL_STRESS_TEST_PL "mysql-stress-test.pl" Perl
script performs stress-testing of the MySQL server.
</li>
<li>
A unit-testing facility is provided so that individual unit test
programs can be created for storage engines and plugins.
</li>
</ul>
Test suite programs can be found in these locations:
<ul>
<li>
For a source distribution, @ref PAGE_MYSQLTEST "mysqltest" is in
the <b>client</b> directory. For a binary distribution, it is in
the MySQL <b>bin</b> directory.
</li>
<li>
For a source distribution, @ref PAGE_MYSQL_CLIENT_TEST
"mysql_client_test" is in the <b>tests</b> directory. For a
binary distribution, it is in the MySQL <b>bin</b> directory.
</li>
<li>
The other programs are located in the <b>mysql-test</b>
directory. For a source distribution, <b>mysql-test</b> is found
under the source tree root. For a binary distribution, the
location of <b>mysql-test</b> depends on the layout used for the
distribution format.
</li>
</ul>
Test Framework Directories and Files
-------------------------------------
The test suite is located in the <tt>mysql-test</tt> directory,
which contains the following components:
<ul>
<li>
The @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" and @ref
PAGE_MYSQL_STRESS_TEST_PL "mysql-stress-test.pl" programs that
are used for running tests.
</li>
<li>
The <b>t</b> directory contains test case input files. A test
case file might also have additional files associated with it.
</li>
<ul>
<li>
A file name of the form <b><em>test_name</em>.test</b> is a
test case file for a test named <b><em>test_name</em></b>. For
example, <b>subquery.test</b> is the test case file for the
test named <b>subquery</b>.
</li>
<li>
A file name of the form <b><em>test_name</em>-master.opt</b>
provides options to associate with the named test case.
<b>mysql-test-run.pl</b> 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 <b>-master.opt</b> file is used for the “main”
server of a test, even if no replication is involved.
</li>
<li>
A file name of the form <b><em>test_name</em>-slave.opt</b>
provides slave options.
</li>
<li>
Server options which need to be passed during initialization
of the server can be passed in both
<b><em>test_name</em>-master.opt</b> and
<b><em>test_name</em>-slave.opt</b>. Each bootstrap variable
must be passed as the value of a <b>`--initialize`</b> option so
that @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" can
recognize that the variable should be used during server
initialization, remove the existing data directory, and
initialize a new data directory with the options provided.
@ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" will also
start the server afterwards, with the bootstrap options, and
other options specified.
</li>
<li>
A file name of the form <b><em>test_name</em>-client.opt </b>
provides @ref PAGE_MYSQLTEST "mysqltest" client options.
</li>
<li>
A file name of the form <b><em>test_name</em>.cnf</b> contains
additional entries for the config file to be used for this
test.
<ul>
<li>
During a test run, each server is started with a different
<b>defaults-group-suffix</b> value and this suffix value
can be used with a group name to specify server specific
options. For example, section <b>[mysqld.1]</b> is used to
specify options for mysqld server with suffix value
<b>".1"</b>.
</li>
<li>
The <b>[mysqltest]</b> section is used to specify options
for mysqltest client.
</li>
<li>
The <b>[ENV]</b> section is used to specify environment
variables for a test case.
</li>
<li>
To include the options mentioned in another <b>.cnf</b>
file, <b>!include path_to_cnf_file</b> is used. Path to
the included <b>.cnf</b> should either be an absolute path
or a relative path from current location or from
<b>mysql-test</b> directory.
</li>
</ul>
Here is a sample <b>.cnf</b> file.
@verbatim
!include include/default_my.cnf
[mysqld.1]
Options for server mysqld.1
[mysqld.2]
Options for server mysqld.2
[mysqltest]
ps-protocol
...
...
...
[ENV]
SERVER_MYPORT_1= @mysqld.1.port
SERVER_MYPORT_2= @mysqld.2.port
@endverbatim
</li>
<li>
A file name of the form <b><em>test_name</em>.combinations</b>
provides section of options for each test run.
</li>
<li>
A file name of the form <b><em>suite</em>.opt</b> provides
server options to all the tests within the suite it belongs
to.
If a test run is started with more than one server, the
options specified in a <b><em>suite</em>.opt</b> are used by
all of them. It is also possible to pass the server options
needed during the server initialization in the
<b><em>suite</em>.opt</b> file.
The options mentioned in the <b><em>suite</em>.opt</b> file
are overridden by those found in a
<b><em>test_name</em>-master.opt</b> file or in a
<b><em>test_name</em>-slave.opt</b> file.
</li>
<li>
A file name of the form <b><em>test_name</em>-master.sh</b> is
a shell script that will be executed before the server is
started for the named test case. There may also be a
<b><em>test_name</em>-slave.sh</b> which is executed before
the slave server is started.
These files will not work on Windows and may therefore be
replaced with a more portable mechanism in the future.
</li>
<li>
The <b>disabled.def</b> 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 @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl", list the test in
this file.
The format of a line in the <b>disabled.def</b> file looks
like this, where fields are separated by one or more spaces.
@verbatim
suite_name.test_name [@platform|@!platform] : <BUG|WL>#<XXXX> [<comment>]
@endverbatim
Example:
@verbatim
main.1st @linux : BUG#18980 Test fails randomly
@endverbatim
<b><em>suite_name</em></b> is the suite name.
<b><em>test_name</em></b> is the test case name.
An additional element after the test name and before the
colon you may add a <b>\@<em>platform</em></b> to have the
test disabled only on a specific platform. Basic OS names as
reported by <b>$^O</b> in Perl, or <b>'windows'</b> are
supported. Alternatively, <b>@!<em>platform</i></b> will
disable the test on all except the named platform.
<b>BUG#<em>nnnnn</em></b> or <b>WL#<em>nnnn</em></b> indicates
the bug or the WL related to the test that causes it to fail
(and thus requires it to be disabled).
The <b><em>comment</em></b> text following the
<b>BUG#<em>nnnnn</em></b> or the <b>WL#<em>nnnn</em></b> is
not part of the mandatory syntax for this file,
@ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" will not
actually care what is written here. Length of a
<b><em>comment</em></b> text must not be more than <b>80</b>
characters.
A comment line can be written in the file by beginning the
line with a “<b>#</b>” character.
</li>
</ul>
<li>
The <b>r</b> directory contains test case result files:
<ul>
<li>
A file name of the form <b><em>test_name</em>.result</b> is
the expected result for the named test case. A file
<b>r/<em>test_name</em>.result</b> is the output that
corresponds to the input in the test case file
<b>t/<em>test_name</em>.test</b>.
</li>
<li>
A file name of the form <b><em>test_name</em>.reject</b>
contains output for the named test case if the test fails
due to output mismatch (but not it it fails for other
reasons).
</li>
</ul>
For a test case that succeeds, the <b>.result</b> file
represents both the expected and actual result. For a test case
that fails, the <b>.result</b> file represents the expected
result, and the <b>.reject</b> file represents the actual
result.
If a <b>.reject</b> file is created because a test fails, @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" removes the file
later the next time the test succeeds.
When <b>`--check-testcases`</b> option is enabled, a test case
not having its corresponding <b>.result</b> file is marked as
failed by MTR. See @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl".
</li>
<li>
The <b>include</b> directory contains files that are included by
test case files using the <b>source</b> 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 @ref PAGE_INCLUDE_FILES.
</li>
<li>
The <b>lib</b> directory contains library files used by @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl", and database
initialization SQL code.
</li>
<li>
The <b>std_data</b> directory contains data files used by some
of the tests.
</li>
<li>
The <b>var</b> 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.
</li>
<li>
The <b>suite</b> directory contains a set of subdirectories
containing named test suites. Each subdirectory represents a
test suite with the same name.
A test suite directory contains the following components:
<ul>
<li>
The <b>t</b> directory contains test cases.
</li>
<li>
The <b>r</b> directory contains test case result files.
</li>
<li>
The <b>include</b> directory contains files that are
included by the test cases belonging to that suite.
</li>
<li>
A file name of the form <b>combinations</b> provides section
of options for each test run. See @ref
PAGE_CONTROLLING_BINARY_LOG_FORMAT.
</li>
<li>
A file name of the form <b><em>my</em>.cnf</b> contains
additional entries for the config file used by all the tests
within the suite it belongs to.
A suite specific <b><em>my</em>.cnf</b> file is overridden
by a <b><em>test_name</em>.cnf</b> file.
</li>
</ul>
</li>
<li>
The <b>collections</b> directory contains collections of test
runs that are run during integration and release testing of
MySQL. They are not directly useful outside this context, but
need to be part of the source repository and are included for
reference.
</li>
</ul>
Unit test-related files are located in the <b>unittest</b>
directory. Additional files specific to storage engines and plugins
may be present under the subdirectories of the <b>storage</b> or
<b>plugin</b> directories.
Test Execution and Evaluation
-----------------------------
There are a number of targets in the top-level <b>Makefile</b> that
can be used to run sets of tests. <b>make test</b> only runs unit
tests. Other targets run subsets of the tests, or run tests with
specific options for the test programs. Have a look at the
<b>Makefile</b> 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 <b><em>not</em></b>
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:
<ul>
<li>
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.
</li>
<li>
The result from @ref PAGE_MYSQLTEST "mysqltest" commands such as
<b>echo</b> and <b>exec</b>. The commands themselves are not
echoed to the result, only their output.
</li>
</ul>
The <b>disable_query_log</b> and <b>enable_query_log</b> commands
control logging of input SQL statements. The
<b>disable_result_log</b> and <b>enable_result_log</b> commands
control logging of SQL statement results, and warning or error
messages resulting from those statements.
@ref PAGE_MYSQLTEST "mysqltest" reads a test case file from its
standard input by default. The <b>`--test-file`</b> or <b>-x</b>
option can be given to name a test case file explicitly.
@ref PAGE_MYSQLTEST "mysqltest" writes test case output to the
standard output by default. The <b>`--result-file`</b> or <b>-R</b>
option can be used to indicate the location of the result file. That
option, together with the <b>`--record`</b> option, determine how
@ref PAGE_MYSQLTEST "mysqltest" treats the test actual and expected
results for a test case:
<ul>
<li>
If the test produces no results, @ref PAGE_MYSQLTEST "mysqltest"
exits with an error message to that effect, unless
<b>`--result-file`</b> is given and this file is empty.
</li>
<li>
Otherwise, if <b>`--result-file`</b> is not given, @ref
PAGE_MYSQLTEST "mysqltest" sends test results to the standard
output.
</li>
<li>
With <b>`--result-file`</b> but not <b>`--record`</b>, @ref
PAGE_MYSQLTEST "mysqltest" reads the expected results from the
given file and compares them with the actual results. If the
results do not match, @ref PAGE_MYSQLTEST "mysqltest" writes a
<b>.reject</b> file in the log directory and exits with an
error. It will also print out a diff of the expected and actual
result, provided it can find an appropriate
<b>diff</b> tool to use.
</li>
<li>
With both <b>`--result-file`</b> and <b>`--record`</b>, @ref
PAGE_MYSQLTEST "mysqltest" updates the given file by writing the
actual test results to it. The file does not need to pre-exist.
</li>
</ul>
@ref PAGE_MYSQLTEST "mysqltest" itself knows nothing of the <b>t</b>
and <b>r</b> directories under the <b>mysql-test</b> directory. The
use of files in those directories is a convention that is used by
@ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl", which invokes @ref
PAGE_MYSQLTEST "mysqltest" with the appropriate options for each
test case to tell @ref PAGE_MYSQLTEST "mysqltest" where to read input
and write output.
*/
###############################################################################
## Test Framework System Requirements
/**
@page PAGE_TEST_FRAMEWORK_SYSTEM_REQUIREMENTS Test Framework System Requirements
The @ref PAGE_MYSQLTEST "mysqltest" and @ref PAGE_MYSQL_CLIENT_TEST
"mysql_client_test" programs are written in C++ and are available on
any system where MySQL itself can be compiled, or for which a binary
MySQL distribution is available.
Other parts of the test framework such as @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" are Perl scripts and
should run on systems with Perl installed.
@ref PAGE_MYSQLTEST "mysqltest" uses the <b>diff</b> program to
compare expected and actual test results. If <b>diff</b> is not
found, @ref PAGE_MYSQLTEST "mysqltest" writes an error message and
dumps the entire contents of the <b>.result</b> and
<b>.reject</b> files so that you can try to determine why a test
did not succeed. If your system does not have <b>diff</b>, you may
be able to obtain it from one of these sites:
- http://www.gnu.org/software/diffutils/diffutils.html
- http://gnuwin32.sourceforge.net/packages/diffutils.htm
@ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" cannot function
properly if started from within a directory whose full path includes
a space character, due to the complexities of handling this
correctly in all the different contexts it will be used.
*/
###############################################################################
## How to Report Bugs from Tests in the MySQL Test Suite
/**
@page PAGE_REPORT_BUGS How to Report Bugs from Tests in the MySQL Test Suite
If test cases from the test suite fail, you should do the following:
<ul>
<li>
Do not file a bug report before you have found out as much as
possible about what when wrong. See the instructions at
https://dev.mysql.com/doc/refman/8.0/en/bug-reports.html.
</li>
<li>
Make sure to include the output of @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl", as well as contents of all <b>.reject</b>
files in the <b>mysql-test/var/log</b> directory, or the (often
much shorter) diff that @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl" reported.
</li>
<li>
Check whether an individual test in the test suite also fails
when run on its own:
@verbatim
shell> cd mysql-test
shell> ./mysql-test-run.pl test_name
@endverbatim
If this fails, and you are compiling MySQL yourself, you should
configure MySQL with <b>`--with-debug`</b> and run @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" with the
<b>`--debug`</b> option. If this also fails, open a bug report
and upload the trace file <b>mysql-test/var/tmp/master.trace</b>
to the report, so that we can examine it. For instructions, see
[How to Report Bugs or Problems]
(https://dev.mysql.com/doc/refman/8.0/en/bug-reports.html).
Please remember to also include a full description of your
system, the version of the <b>mysqld</b> binary and how you
compiled it.
</li>
<li>
Run @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" with the
<b>`--force`</b> option to see whether any other tests fail.
</li>
<li>
If you have compiled MySQL yourself, check the MySQL Reference
Manual to see whether there are any platform-specific issues for
your system. There might be configuration workarounds to deal
with the problems that you observe. Also, consider using one of
the binaries we have compiled for you at
https://dev.mysql.com/downloads/. All our standard binaries
should pass the test suite!
</li>
<li>
If you get an error such as <b>Result length mismatch</b> or
<b>Result content mismatch</b> it means that the output of the
test was not an exact match for the expected output. This could
be a bug in MySQL or it could be that your version of
<b>mysqld</b> produces slightly different results under some
circumstances.
This output from @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl"
should include a diff of the expected and actual result. If
unable to produce a diff, it will instead print out both in
full. In addition, the actual result is put in a file in the
<b>r</b> directory with a <b>.result</b> extension.
</li>
<li>
If a test fails completely, you should check the logs file in
the <b>mysql-test/var/log</b> directory for hints of what went
wrong.
</li>
<li>
If you have compiled MySQL with debugging, you can try to debug
test failures by running @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl" with either or both of the <b>`--gdb`</b>
and <b>`--debug`</b> options.
If you have not compiled MySQL for debugging you should probably
do so by specifying the [-DWITH_DEBUG]
(https://dev.mysql.com/doc/refman/8.0/en/source-configuration-options.html#option_cmake_with_debug)
option when you invoke <b>CMake</b>.
</li>
</ul>
*/
###############################################################################
## Running Test Cases
/**
@page PAGE_RUNNING_TESTCASES Running Test Cases
Typically, you run the test suite either from within a source tree
(after MySQL has been built), or on a host where the MySQL server
distribution has been installed. (If you find that the test suite is
not included in your distribution, look for a similar distribution
with <b>-test</b> in the name and install that as well.)
To run tests, your current working directory should be the
<b>mysql-test</b> directory of your source tree or installed
distribution. In a source distribution, <b> mysql-test</b> is
under the root of the source tree. In a binary distribution, the
location of <b>mysql-test</b> depends on the distribution layout.
The program that runs the test suite, @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl", will figure out whether you are in a source
tree or an installed directory tree.
To run the test suite, change location into your <b>mysql-test</b>
directory and invoke the @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl" script:
@verbatim
shell> cd mysql-test
shell> ./mysql-test-run.pl
@endverbatim
@ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" accepts options on
the command line. For example:
@verbatim
shell> ./mysql-test-run.pl --force --suite=binlog
@endverbatim
By default, @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" exits if
a test case fails. <b>`--force`</b> causes execution to continue
regardless of test case failure.
For a full list of the supported options, see @ref
PAGE_MYSQL_TEST_RUN_PL.
To run one or more specific test cases, name them on the @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" command line. Test case
files have names like <b>t/<em>test_name</em>.test</b>, where
<b><em>test_name</em></b> is the name of the test case, but each name
given on the command line should be the test case name, not the full
test case file name. The following command runs the test case named
<b>rpl_abcd</b>, which has a test file of
<b>t/rpl_abcd.test</b>:
@verbatim
shell> ./mysql-test-run.pl rpl_abcd
@endverbatim
To run a family of test cases for which the names share a common
prefix, use the <b>`--do-test`</b> option:
@verbatim
shell> ./mysql-test-run.pl --do-test=prefix
@endverbatim
For example, the following command runs the events tests (test
cases that have names beginning with <b>events</b>):
@verbatim
shell> ./mysql-test-run.pl --do-test=events
@endverbatim
To run a specific named testsuite with all the test cases in it,
use the <b>`--suite`</b> option:
@verbatim
shell> ./mysql-test-run.pl --suite=suite_name
@endverbatim
For example, the following command runs the replication tests
located in the <b>rpl</b> suite:
@verbatim
shell> ./mysql-test-run.pl --suite=rpl
@endverbatim
@ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" starts the MySQL
server, sets up the environment for calling the @ref PAGE_MYSQLTEST
"mysqltest" program, and invokes @ref PAGE_MYSQLTEST "mysqltest" to
run the test case. For each test case to be run, @ref PAGE_MYSQLTEST
"mysqltest" handles operations such as reading input from the test
case file, creating server connections, and sending SQL statements
to servers.
The language used in test case files is a mix of commands that the
@ref PAGE_MYSQLTEST "mysqltest" program understands and SQL
statements. Input that @ref PAGE_MYSQLTEST "mysqltest" doesn't
understand is assumed to consist of SQL statements to be sent to the
database server. This makes the test case language familiar to those
that know how to write SQL and powerful enough to add the control
needed to write test cases.
You need not start a MySQL server first before running tests.
Instead, the @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" program
will start the server or servers as needed. Any servers started for
the test run use ports in the range from 13000 by default.
@section SECTION_RUNNING_TESTS_IN_PARALLEL Running Tests in Parallel
It is possible to run more than one instance of @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" simultaneously on the
same machine. Both will by default use server ports from 13000 but
will coordinate used port numbers as well as check for availibility,
to avoid conflicts.
Running several instances from the same <b>mysql-test</b>
directory is possible but problematic. You must the use the
<b>`--vardir`</b> to set different log directories for each
instance. Even so, you can get into trouble becuse they will write
<b>.reject</b> files to the same directories.
It is also possible to have a single @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl" run tests in several threads in parallel.
Execution of the tests will be distributed among the threads. This
is achieved using the <b>`--parallel`</b> option, with the number
of threads as argument. The special value <b>auto</b> will ask
@ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" to pick a value
automatically, based on system information. The parallel option may
also be given using the environment variable <b>MTR_PARALLEL</b>.
@note
Test cases which use <b>not_parallel.inc</b> are run at the end with
a parallel value of <b>1</b> overriding the <b>`--parallel`</b>
option value. Such test cases will be executed at the end of the test
run one at a time. These tests also require
<b>`--non-parallel-test`</b> option to be ON.
*/
###############################################################################
## Writing Test Cases
/**
@page PAGE_WRITING_TESTCASES Writing Test Cases
<h3>Table of Contents</h3>
- @subpage PAGE_QUICK_START
- @subpage PAGE_TESTCASE_CODING_GUIDELINES
- @subpage PAGE_SAMPLE_TESTCASES
- @subpage PAGE_CLEANUP_PREVIOUS_TEST_RUN
- @subpage PAGE_GENERATE_TESTCASE_RESULT_FILE
- @subpage PAGE_CHECK_EXPECTED_ERRORS
- @subpage PAGE_CONTROL_INFORMATION_PRODUCED_TESTCASE
- @subpage PAGE_DEALING_OUTPUT
- @subpage PAGE_PASSING_OPTIONS
- @subpage PAGE_TESTCASE_SPECIFIC_SERVER_OPTIONS
- @subpage PAGE_TESTCASE_SPECIFIC_BOOTSTRAP_OPTIONS
- @subpage PAGE_TESTCASE_SPECIFIC_CLIENT_OPTIONS
- @subpage PAGE_INCLUDE_FILES
- @subpage PAGE_BINARY_LOG_FORMAT
- @subpage PAGE_WRITING_REPLICATION_TESTS
- @subpage PAGE_THREAD_SYNCHRONIZATION
- @subpage PAGE_SUPPRESSING_ERRORS_WARNINGS
- @subpage PAGE_STOPPING_AND_RESTARTING_SERVER_DURING_TEST
- @subpage PAGE_TIPS_WRITING_TESTCASES
Normally, you run the test suite during the development process to
ensure that your changes do not cause existing test cases to break.
You can also write new test cases or add tests to existing cases.
This happens when you fix a bug (so that the bug cannot reappear
later without being detected) or when you add new capabilities to
the server or other MySQL programs.
This chapter provides guidelines for developing new test cases for
the MySQL test framework.
Some definitions:
- One “test file” is one “test case”.
- One “test case” might contain a “test sequence” (that is, a
number of individual tests that are grouped together in the same
test file).
- A “command” is an input test that @ref PAGE_MYSQLTEST "mysqltest"
recognizes and executes itself. A “statement” is an SQL statement
or query that @ref PAGE_MYSQLTEST "mysqltest" sends to the MySQL
server to be executed.
*/
###############################################################################
## Writing a Test Case: Quick Start
/**
@page PAGE_QUICK_START Writing a Test Case: Quick Start
The basic principle of test case evaluation is that output resulting
from running a test case is compared to the expected result. This is
just a <b>diff</b> comparison between the output and an expected-result
file that the test writer provides. This simplistic method of
comparison does not by itself provide any way to handle variation in
the output that may occur when a test is run at different times.
However, the test language provides commands for postprocessing
result output before the comparison occurs. This enables you to
manage certain forms of expected variation.
Use the following procedure to write a new test case. In the
examples, <b><em>test_name</em></b> represents the name of the test
case. It is assumed here that you'll be using a development source
tree, so that when you create a new test case, you can commit the
files associated with it to the source repository for others to use.
<ol>
<li>
Change location to the test directory
<b>mysql-<em>version</em>/mysql-test</b>:
@verbatim
shell> cd mysql-version/mysql-test
@endverbatim
<b>mysql-<em>version</em></b> represents the root directory of
your source tree.
</li>
<li>
Create the test case in a file
<b>t/<em>test_name</em>.test</b>. You can do this with
any text editor. For details of the language used for writing
@ref PAGE_MYSQLTEST "mysqltest" test cases, see @ref
PAGE_MYSQLTEST_LANGUAGE_REFERENCE.
</li>
<li>
Create an empty result file:
@verbatim
shell> touch r/test_name.result
@endverbatim
</li>
<li>
Run the test:
@verbatim
shell> ./mysql-test-run.pl test_name
@endverbatim
</li>
<li>
Assuming that the test case produces output, it should fail
because the output does not match the result file (which is
empty at this point). The failure results in creation of a
reject file named
<b>mysql-test/var/log/<em>test_name</em>.reject</b>.
Examine this file. If the reject file appears to contain the
output that you expect the test case to produce, copy its
content to the result file:
@verbatim
shell> cp mysql-test/var/log/test_name.reject r/test_name.result
@endverbatim
Another way to create the result file is by invoking @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" with the
<b>`--record`</b> option to record the test output in the
result file:
@verbatim
shell> ./mysql-test-run.pl --record test_name
@endverbatim
</li>
<li>
Run the test again. This time it should succeed:
@verbatim
shell> ./mysql-test-run.pl test_name
@endverbatim
You can also run the newly created test case as part of
the entire suite:
@verbatim
shell> ./mysql-test-run.pl
@endverbatim
</li>
</ol>
It is also possible to invoke the @ref PAGE_MYSQLTEST "mysqltest"
program directly. If the test case file refers to environment
variables, you will need to define those variables in your
environment first. For more information about the @ref
PAGE_MYSQLTEST "mysqltest" program, see @ref PAGE_MYSQLTEST.
*/
###############################################################################
## Test Case Coding Guidelines
/**
@page PAGE_TESTCASE_CODING_GUIDELINES Test Case Coding Guidelines
<h3>Table of Contents</h3>
- @subpage PAGE_NAMING_ORGANIZATION_GUIDELINES
- @subpage PAGE_CONTENT_FORMATTING_GUIDELINES
- @subpage PAGE_NAMING_CONVENTIONS
*/
###############################################################################
## File Naming and Organization Guidelines
/**
@page PAGE_NAMING_ORGANIZATION_GUIDELINES File Naming and Organization Guidelines
Test case file names may use alphanumeric characters (<b>A-Z</b>,
<b>a-z</b>, <b>0-9</b>), underscore (<b>'_'</b>) or dash
(<b>'-'</b>), but should not start with underscore or dash. No other
special characters are allowed, if used, then an error is thrown and
the test run is aborted.
Test names have traditionally used lowercase only, and we recommend
continuing this for tests added to the common repository, though
uppercase letters are also supported.
Test cases are located in the <b>mysql-test/t</b> directory. Test
case file names consist of the test name with a <b>.test</b>
suffix. For example, a test named <b>foo</b> should be written in
the file <b>mysql-test/t/foo.test</b>.
In addition to this directory, tests are organized in test suites,
located in subdirectories under the <b>suite</b> directory. For
example, a test named <b>bar</b> under the replication suite
<b>rpl</b> may be stored in the file <b>mysql-
test/suite/rpl/t/bar.test</b>.
In practice, the file would likely be called <b>rpl_bar.test</b>
as tests in a suite usually also have the suite name as a prefix.
This is just a convention from the time when suites were not
supported, and not a requirement for test naming.
One test case file can be a collection of individual tests that
belong together. If one of the tests fails, the entire test case
fails. Although it may be tempting to write each small test into a
single file, that will be too inefficient and makes test runs
unbearably slow. So make the test case files not too big, not too
small.
Each test case (that is, each test file) must be self contained and
independent of other test cases. Do not create or populate a table
in one test case and depend on the table in a later test case. If
you have some common initialization that needs to be done for
multiple test cases, create an include file. That is, create a file
containing the initialization code in the <b>mysql-test/include</b>
directory, and then put a <b>source</b> command in each test case
that requires the code. For example, if several test cases need to
have a given table created and filled with data, put the statements
to do that in a file named <b>mysql-test/include/create_my_table.inc</b>.
The <b>.inc</b> is a convention, not a requirement. Then put the
following command in each test case file that needs the
initialization code:
@verbatim
--source include/create_my_table.inc
@endverbatim
The file name in the <b>source</b> command is relative to the
<b>mysql-test</b> directory. Remember to drop the table at the
end of each test that creates it.
*/
###############################################################################
## Test Case Content-Formatting Guidelines
/**
@page PAGE_CONTENT_FORMATTING_GUIDELINES Test Case Content-Formatting Guidelines
When you write a test case, please keep in mind the following
general guidelines.
There are C/C++ coding guidelines in the MySQL Internals manual;
please apply them when it makes sense to do so: @ref
PAGE_CODING_GUIDELINES.
Other guidelines may be found in this page, which discusses general
principles of test-case writing: MySQL Internals:
[How to Create Good Test Cases]
(https://dev.mysql.com/doc/internals/en/good-tests.html)
The following guidelines are particularly applicable to writing test
cases:
<ul>
<li>
To write a test case file, use any text editor that uses
linefeed (newline) as the end-of-line character.
</li>
<li>
Avoid lines longer than 80 characters unless there is no
other choice.
</li>
<li>
A comment in a test case is started with the "#" character.
@ref PAGE_MYSQL_TEST_INPUT_CONVENTIONS discusses the details
of input syntax for mysqltest test cases.
</li>
<li>
Use spaces, not tabs.
</li>
<li>
Write SQL statements using the same style as our manual:
<ul>
<li>
Use uppercase for SQL keywords.
</li>
<li>
Use lowercase for identifiers (names of objects such as
databases, tables, columns, and so forth).
</li>
</ul>
Ignore this guidline if your intent is to test lettercase
processing for SQL statements, of course.
Use lowercase for @ref PAGE_MYSQLTEST "mysqltest" commands
(<b>echo</b>, <b>sleep</b>, <b>let,</b> and so forth).
You may notice that many existing test cases currently do not
follow the lettercase guideline and contain SQL statements
written entirely in lowercase. Nevertheless, <b><em>please use
the guideline for new tests</em></b>. Lettercase for older tests
can be left as is, unless perhaps you need to revise them
significantly.
</li>
<li>
Break a long SQL statement into multiple lines to make it more
readable. This means that you will need to write it using a
“<b>;</b>” delimiter at the end of the statement rather than
using “<b>`--`</b>” at the beginning because the latter style
works only for single-line statements.
</li>
<li>
Include comments. They save the time of others. In particular:
<ul>
<li>
Please include a header in test files that indicates the
purpose of the test and references the corresponding worklog
task, if any.
</li>
<li>
Comments for a test that is related to a bug report should
include the bug number and title.
</li>
</ul>
Worklog and bug numbers are useful because they enable people
who are interested in additional background related to the test
case to know which worklog entries or bug reports to read.
</li>
</ul>
Example SQL statement, formatted onto multiple lines for readability:
@verbatim
SELECT f1 AS "my_column", f10 ....
FROM mysqltest1.t5
WHERE (f2 BETWEEN 17 AND 25 OR f2 = 61)
AND f3 IN (SELECT ....
FROM mysqltest1.t4
WHERE .....)
ORDER BY ... ;
@endverbatim
Example test file header:
@verbatim
########### suite/funcs_1/t/a_processlist_val_no_prot.test #############
# #
# Testing of values within INFORMATION_SCHEMA.PROCESSLIST #
# #
# The prepared statement variant of this test is #
# suite/funcs_1/t/b_processlist_val_ps.test. #
# #
# There is important documentation within #
# suite/funcs_1/datadict/processlist_val.inc #
# #
# Note(mleich): #
# The name "a_process..." with the unusual prefix "a_" is #
# caused by the fact that this test should run as second test, that #
# means direct after server startup and a_processlist_priv_no_prot. #
# Otherwise the connection IDs within the processlist would differ. #
# #
# Creation: #
# 2007-08-09 mleich Implement this test as part of #
# WL#3982 Test information_schema.processlist #
# #
########################################################################
@endverbatim
Example test reference to bug report:
@verbatim
# Bug #3671 Stored procedure crash if function has "set @variable=param"
@endverbatim
*/
###############################################################################
## Naming Conventions for Database Objects
/**
@page PAGE_NAMING_CONVENTIONS Naming Conventions for Database Objects
It is possible to run test cases against a production server. This
is very unlikely to happen by accident, as @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" will start its own server
unless you use the <b>`--extern`</b> Even so, try to write test
cases in a way that reduces the risk that running tests will alter
or destroy important tables, views, or other objects. (<b>DROP
DATABASE</b> statements are particularly dangerous if written using
names that could exist on a customer's machine.) To avoid such
problems, we recommend the following naming conventions:
<ul>
<li>
User names: User names should begin with “mysql” (for example,
<b>mysqluser1</b>, <b>mysqluser2</b>)
</li>
<li>
Database names: Unless you have a special reason not to, use
the default database named <b>test</b> that is already created
for you. For tests that need to operate outside the <b>test</b>
database, database names should contain “test” or begin with
“mysql” (for example, <b>mysqltest1</b>, <b>mysqltest2</b>)
</li>
<li>
Table names: <b>t1</b>, <b>t2</b>, <b>t3</b>, ...
</li>
<li>
View names: <b>v1</b>, <b>v2</b>, <b>v3</b>, ...
</li>
</ul>
For examples of how to name objects, examine the existing test
cases. Of course, you can name columns and other objects inside
tables as you wish.
*/
###############################################################################
## Sample Test Case
/**
@page PAGE_SAMPLE_TESTCASES Sample Test Case
Here is a small sample test case:
@verbatim
--disable_warnings
DROP TABLE IF EXISTS t1;
SET @@sql_mode='NO_ENGINE_SUBSTITUTION';
--enable_warnings
SET SQL_WARNINGS=1;
CREATE TABLE t1 (a INT);
INSERT INTO t1 VALUES (1);
INSERT INTO t1 VALUES ("hej");
DROP TABLE t1;
@endverbatim
The first few lines try to clean up from possible earlier runs of
the test case by dropping the <b>t1</b> table. The test case uses
<b>disable_warnings</b> to prevent warnings from being written to
the output because it is not of any interest at this point during
the test to know whether the table <b>t1</b> was there. The value of
<b>sql_mode</b> is changed to <b>NO_ENGINE_SUBSTITUTION</b> to avoid
the error thrown by the second insert statement. After this, the
test case uses <b>enable_warnings</b> so that subsequent warnings
will be written to the output. The test case also enables verbose
warnings in MySQL using the <b>SET SQL_WARNINGS=1;</b> statement.
Next, the test case creates the table <b>t1</b> and tries some
operations. Creating the table and inserting the first row are
operations that should not generate any warnings. The second insert
should generate a warning because it inserts a nonnumeric string
into a numeric column. At the end, it drops the table <b>t1</b>. The
output that results from running the test looks like this:
@verbatim
DROP TABLE IF EXISTS t1;
SET @@sql_mode='NO_ENGINE_SUBSTITUTION';
SET SQL_WARNINGS=1;
CREATE TABLE t1 (a INT);
INSERT INTO t1 VALUES (1);
INSERT INTO t1 VALUES ("hej");
Warnings:
Warning 1366 Incorrect integer value: 'hej' for column 'a' at row 1
DROP TABLE t1;
@endverbatim
Note that the result includes not only the output from SQL
statements, but the statements themselves. Statement logging can be
disabled with the <b>disable_query_log</b> test language command.
There are several options for controlling the amount of output from
running the tests.
If there was a test failure, it will be reported to the screen. You
can see the actual output from the last unsuccessful run of the test
case in the reject file
<b>mysql-test/var/log/<em>test_name</em>.reject</b>.
*/
###############################################################################
## Cleaning Up from a Previous Test Run
/**
@page PAGE_CLEANUP_PREVIOUS_TEST_RUN Cleaning Up from a Previous Test Run
For efficiency, the @ref PAGE_MYSQLTEST "mysqltest" test engine does
not start with a clean new database for running each test case, so a
test case generally starts with a “cleaning up section”. Assume that
a test case will use two tables named <b>t1</b> and <b>t2</b>.
The test case should begin by making sure that any old tables with
those names do not exist:
@verbatim
--disable_warnings
DROP TABLE IF EXISTS t1,t2;
--enable_warnings
@endverbatim
The <b>disable_warnings</b> command instructs the test engine not
to log any warnings until an <b>enable_warnings</b> command occurs
or the test case is ended. (MySQL generates a warning if the table
<b>t1</b> or <b>t2</b> does not exist.) Surrounding this part of
the test case with commands to disable and enable warnings makes its
output the same regardless of whether the tables exist before the
test is started. After ensuring that the tables do not exist, we are
free to put in any SQL statements that create and use the tables
<b>t1</b> and <b>t2</b>. The test case should also clean up at
the end of the test by dropping any tables that it creates.
Let's put in some SQL code into this test case:
@verbatim
--disable_warnings
DROP TABLE IF EXISTS t1,t2;
--enable_warnings
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;
SELECT * FROM t1;
SELECT t1.* FROM t1;
SELECT * FROM t1 INNER JOIN t2 USING (Period);
DROP TABLE t1, t2;
@endverbatim
If a test case creates other objects such as stored programs or
user accounts, it should take care to also clean those up at the
beginning and end of the test. Temporary files should also be
removed, either at the end or just after they have been used.
*/
###############################################################################
## Generating a Test Case Result File
/**
@page PAGE_GENERATE_TESTCASE_RESULT_FILE Generating a Test Case Result File
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
Note that these are the reasons why @ref PAGE_MYSQLTEST "mysqltest"
would fail; if the test is run from @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl" the test may fail for additional reasons.
In the first case, @ref PAGE_MYSQLTEST "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 <b>`--record`</b> option, like this:
@verbatim
shell> cd mysql-test
shell> ./mysql-test-run.pl --record foo
@endverbatim
Running the test as shown creates a result file named
<b>mysql-test/r/foo.result</b> that has this content:
@verbatim
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
@endverbatim
If we look at this result file, it contains the statements in the
<b>foo.test</b> file together with the output from the
<b>SELECT</b> 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 @ref
PAGE_DEALING_OUTPUT.
*/
###############################################################################
## Checking for Expected Errors
/**
@page PAGE_CHECK_EXPECTED_ERRORS Checking for Expected Errors
A good test suite checks not only that operations succeed as they
ought, but also that they fail as they ought. For example, if a
statement is illegal, the server should reject it with an error
message. The test suite should verify that the statement fails and
that it fails with the proper error message.
The test engine enables you to specify “expected failures.” Let's
say that after we create <b>t1</b>, we try to create it again
without dropping it first:
@verbatim
--disable_warnings
DROP TABLE IF EXISTS t1,t2;
--enable_warnings
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;
SELECT * FROM t1;
SELECT t1.* FROM t1;
SELECT * FROM t1 INNER JOIN t2 USING (Period);
CREATE TABLE t1 (something SMALLINT(4));
@endverbatim
The result is failure and an error:
@verbatim
At line 21: query 'CREATE TABLE t1 (something SMALLINT(4))'
failed: 1050: Table 't1' already exists
@endverbatim
To handle this error and indicate that indeed we do expect it to
occur, we can put an <b>error</b> command before the second
<b>create table</b> statement. Either of the following commands
test for this particular MySQL error:
@verbatim
--error 1050
--error ER_TABLE_EXISTS_ERROR
@endverbatim
<b>1050</b> is the numeric error code and
<b>ER_TABLE_EXISTS_ERROR</b> is the symbolic name. Symbolic names
are more stable than error numbers because the numbers sometimes
change, particularly for those created during recent development.
For such errors, use of numbers rather than the names in a test case
will require test to be revised should the numbers change.
After we make a change to add an <b>error</b> command before the
<b>CREATE TABLE</b> statement and run the test again, the end of
the result will look like this:
@verbatim
CREATE TABLE t1 (something SMALLINT(4));
ERROR 42S01: Table 't1' already exists
@endverbatim
In this case, the result shows the statement that causes the error,
together with the resulting error message. The fact that @ref
PAGE_MYSQLTEST "mysqltest" does not terminate and that the error
message becomes part of the result indicates that the error was
expected.
You can also test for errors by specifying an SQLSTATE value. For
MySQL error number <b>1050</b>, the corresponding SQLSTATE value
is <b>42S01</b>. To specify an SQLSTATE value in an <b>error</b>
command, use an <b>S</b> prefix:
@verbatim
--error S42S01
@endverbatim
A disadvantage of SQLSTATE values is that sometimes they correspond
to more than one MySQL error code. Using the SQLSTATE value in this
case might not be specific enough (it could let through an error
that you do not actually expect).
If you want to test for multiple errors, the <b>error</b> command
allows multiple arguments, separated by commas. For example:
@verbatim
--error ER_NO_SUCH_TABLE,ER_KEY_NOT_FOUND
@endverbatim
For a list of MySQL error codes, symbolic names, and SQLSTATE values,
see https://dev.mysql.com/doc/refman/8.0/en/error-messages-server.html.
You can also examine the <b>mysqld_error.h</b> and
<b>sql_state.h</b> files in the <b>include</b> directory of a MySQL
source distribution.
It is also possible to use symbolic error names to refer to client
errors:
@verbatim
--error CR_SERVER_GONE_ERROR
@endverbatim
For a list of MySQL client error codes, see
https://dev.mysql.com/doc/refman/8.0/en/error-messages-client.html.
You can also examine the <b>errmsg.h</b> file in the <b>include</b>
directory of a MySQL source distribution.
The built-in variable <b>$mysql_errno</b> contains the numeric
error returned by the most recent SQL statement sent to the server,
or 0 if the statement executed successfully. This may be useful
after statements that may or may not fail, or fail in more than one
way (more than one argument to the <b>error</b> command), in case
you need to perform different actions. Note that this applies to SQL
statements, not to other commands.
There is also a variable <b>$mysql_errname</b> which contains the
symbolic name of the last error. In some cases the symbolic name is
not available; in those cases the variable will contain the string
<b>"<Unknown>"</b>. For new test development we recommend testing
against the name rather than the number, since the number may change
in future versions. If the last statement succeeded
(<b>$mysql_errno</b> is 0), this variable is an empty string.
*/
###############################################################################
## Controlling the Information Produced by a Test Case
/**
@page PAGE_CONTROL_INFORMATION_PRODUCED_TESTCASE Controlling the Information Produced by a Test Case
By default, the @ref PAGE_MYSQLTEST "mysqltest" test engine produces
output only from <b>select</b>, <b>show</b>, and other SQL
statements that you expect to produce output (that is, statements
that create a result set). It also produces output from certain
commands such as <b>echo</b> and <b>exec</b>. @ref
PAGE_MYSQLTEST "mysqltest" can be instructed to be more or less
verbose.
Suppose that we want to include in the result the number of rows
affected by or returned by SQL statements. To do this, add the
following line to the test case file preceding the first
table-creation statement:
@verbatim
--enable_info
@endverbatim
After rerunning the test by invoking @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl" with the <b>`--record`</b> option to record
the new result, the result file will contain more information:
@verbatim
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
);
affected rows: 0
CREATE TABLE t2 (Period SMALLINT);
affected rows: 0
INSERT INTO t1 VALUES (9410,9412);
affected rows: 1
INSERT INTO t2 VALUES (9410),(9411),(9412),(9413);
affected rows: 4
info: Records: 4 Duplicates: 0 Warnings: 0
SELECT period FROM t1;
period
9410
affected rows: 1
SELECT * FROM t1;
Period Varor_period
9410 9412
affected rows: 1
SELECT t1.* FROM t1;
Period Varor_period
9410 9412
affected rows: 1
SELECT * FROM t1 INNER JOIN t2 USING (Period);
Period Varor_period
9410 9412
affected rows: 1
DROP TABLE t1, t2;
affected rows: 0
ok
@endverbatim
To turn off the affected-rows reporting, add this command to the
test case file:
@verbatim
--disable_info
@endverbatim
In general, options can be enabled and disabled for different parts
of the test file. Suppose that we are interested in the internals of
the database as well. We could enable the display of query metadata
using <b>enable_metadata</b>. With this option enabled, the test
output is a bit verbose. However, as mentioned earlier, the option
can be enabled and disabled selectively so that it is enabled only
for those parts of the test case where it interests you to know
more.
If you perform an operation for which you have no interest in seeing
the statements logged to the result, you can disable statement
logging. For example, you might be initializing a table where you
don't really expect a failure, and you are not interested in seeing
the initialization statements in the test result. You can use the
<b>disable_query_log</b> command to temporarily disable recording
of input SQL statements, and enable recording again with
<b>enable_query_log</b>. You can disable the recording of the
output from executing commands using <b>disable_result_log</b> and
enable recording again with <b>enable_result_log</b>.
*/
###############################################################################
## Dealing with Output That Varies Per Test Run
/**
@page PAGE_DEALING_OUTPUT Dealing with Output That Varies Per Test Run
It is best to write each test case so that the result it produces
does not vary for each test run, or according to factors such as the
time of day, differences in how program binaries are compiled, the
operating system, and so forth. For example, if the result contains
the current date and time, the test engine has no way to verify that
the result is correct.
However, sometimes a test result is inherently variable according to
external factors, or perhaps there is a part of a result that you
simply do not care about. @ref PAGE_MYSQLTEST "mysqltest" provides
commands that enable you to postprocess test output into a more
standard format so that output variation across test runs will not
trigger a result mismatch.
One such command is <b>replace_column</b>, which specifies that
you want to replace whatever is in a given column with a string.
This makes the output for that column the same for each test run.
To see how this command works, add the following row after the first
insert in the test case:
@verbatim
INSERT INTO t1 VALUES (DATE_FORMAT(NOW(), '%s'),9999);
@endverbatim
Then record the test result and run the test again:
@verbatim
shell> ./mysql-test-run.pl --record foo
shell> ./mysql-test-run.pl foo
@endverbatim
Most likely, a failure will occur and @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl" will display the difference between the expected
result and what we actually got, like this (the header has been
simplified):
@verbatim
CURRENT_TEST: main.foo
--- r/foo.result 2009-11-17 16:22:38
+++ var/log/foo.reject 2009-11-17 16:22:47
@@ -10,15 +10,15 @@
SELECT period FROM t1;
period
9410
-0038
+0047
SELECT * FROM t1;
Period Varor_period
9410 9412
-0038 9999
+0047 9999
SELECT t1.* FROM t1;
Period Varor_period
9410 9412
-0038 9999
+0047 9999
SELECT * FROM t1 INNER JOIN t2 USING (Period);
Period Varor_period
9410 9412
mysqltest: Result content mismatch
@endverbatim
The actual numbers will likely be different for your case, and the
format of the diff may also vary.
If we are not really interested in the first column, one way to
eliminate this mismatch is by using the <b>replace_column</b>
command. The duration of the effect of this command is the next SQL
statement, so we need one before each <b>select</b> statement:
@verbatim
--replace_column 1 SECONDS
SELECT period FROM t1;
--replace_column 1 SECONDS
SELECT * FROM t1;
--replace_column 1 SECONDS
SELECT t1.* FROM t1;
@endverbatim
In the <b>replace_column</b> commands, <b>SECONDS</b> could be
any string. Its only purpose is to map variable output onto a
constant value. If we record the test result again, we will succeed
each time we run the test after that. The result file will look like
this:
@verbatim
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
);
affected rows: 0
CREATE TABLE t2 (Period SMALLINT);
affected rows: 0
INSERT INTO t1 VALUES (9410,9412);
affected rows: 1
INSERT INTO t1 VALUES (DATE_FORMAT(NOW(), '%s'),9999);
affected rows: 1
INSERT INTO t2 VALUES (9410),(9411),(9412),(9413);
affected rows: 4
info: Records: 4 Duplicates: 0 Warnings: 0
SELECT period FROM t1;
period
SECONDS
SECONDS
affected rows: 2
SELECT * FROM t1;
Period Varor_period
SECONDS 9412
SECONDS 9999
affected rows: 2
SELECT t1.* FROM t1;
Period Varor_period
SECONDS 9412
SECONDS 9999
affected rows: 2
SELECT * FROM t1 INNER JOIN t2 USING (Period);
Period Varor_period
9410 9412
affected rows: 1
DROP TABLE t1, t2;
affected rows: 0
ok
@endverbatim
*/
###############################################################################
## Passing Options from mysql-test-run.pl to mysqld or mysqltest
/**
@page PAGE_PASSING_OPTIONS Passing Options from mysql-test-run.pl to mysqld or mysqltest
@ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" supports several
options that enable you to pass options to other programs. Each of
these options takes a value consisting of one or more comma-separated
options:
<ul>
<li>
The <b>`--mysqld`</b> option tells @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl" to start the <b>mysqld</b> server with the
named option added. More than one such extra option may be
provided. The following command causes <b>`--big-tables`</b>
and <b>`--key_buffer_size`=16384</b> to be passed to
<b>mysqld</b>:
@verbatim
shell> ./mysql-test-run.pl
--mysqld=--big-tables
--mysqld=--key_buffer_size=16384
@endverbatim
Note how <b>`--mysqld`</b> needs to be repeated for each
server option to add. It does not work to add several server
options with one <b>`--mysqld`</b> even if enclosed in
quotation marks, as that will be interpreted as a single server
option (including spaces).
</li>
<li>
The <b>`--combination`</b> option is similar to
<b>`--mysqld`</b>, but behaves differently. @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" executes multiple
test runs, using the options for each instance of
<b>`--combination`</b> in successive runs. The following
command passes <b>`--big-tables`</b> to <b>mysqld</b> for the
first test run, <b>`--innodb`</b> for the second run and
<b>`--innodb-file-per-table`</b> for the last run:
@verbatim
shell> ./mysql-test-run.pl
--combination=--big-tables
--combination=--innodb
--combination=--innodb-file-per-table
@endverbatim
If <b>`--combination`</b> is given only once, it behaves similar
to <b>`--mysqld`</b> option.
For test runs specific to a given test suite, an alternative to
the use of the <b>`--combination`</b> option is to create a
<b>combinations</b> file in the suite directory. The file should
contain a section of options for each test run. For an example,
see @ref PAGE_BINARY_LOG_FORMAT.
<b>combinations</b> file can support <b>bootstrap</b> variables
too. The <b>bootstrap</b> variable has to be passed as a value
to the <b>`initialize`</b> keyword.
For a test specific combinations, an alternative to the use of
the <b>`--combination`</b> option is to create a
<b><em>test_name</em>.combinations</b> file in the test
directory.
</li>
<li>
The <b>`--mysqltest`</b> option is used to pass extra options
to @ref PAGE_MYSQLTEST "mysqltest".
@verbatim
shell> ./mysql-test-run.pl --mysqltest=options
@endverbatim
For an example, see @ref PAGE_MYSQL_TEST_RUN_PL.
</li>
</ul>
*/
###############################################################################
## Specifying Test Case-Specific Server Options
/**
@page PAGE_TESTCASE_SPECIFIC_SERVER_OPTIONS Specifying Test Case-Specific Server Options
Within a test case, many system variables can be set by using
statements such as these:
@verbatim
SET sql_warnings= 1;
SET sql_mode= 'NO_AUTO_VALUE_ON_ZERO';
@endverbatim
But sometimes you need to restart the server to use command-line
options that are specific to a given test case. You can specify
these options in a file named
<b>mysql-test/t/<em>test_name-master</em>.opt</b>. When a
file named <b>t/<em>test_name-master</em>.opt</b> exists,
@ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" examines it for
extra options that the server needs to be run with when executing
the <em>test_name</em> test case. If no server has yet been
started or the current server is running with different options,
@ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" restarts the server
with the new options.
You may refer to environment variables in the option file, using the
usual <b><em>$VAR_NAME</em></b> syntax. It is also possible to refer
to optional variables using the syntax <b><em>$?VAR_NAME</em></b>.
This will be replaced with an empty string if the variable is not
set.
As a special case, the option <b>`--skip-core-file`</b> will be
interpreted by @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl",
which will then block the server from producing any core files or
crash dumps during this test. This may be useful for tests that
intentionally crash the server.
Another special case is <b>`--testcase-timeout`=minutes</b> which
can be used to set a different, longer timeout for a particular test
case. The given timeout in minutes will be used for this test if
it's longer than the default.
Files in the <b>mysql-test/t</b> directory with names ending in
<b>-slave.opt</b> are similar, but they are used for slave servers
in replication tests.
Sometimes it's also necessary to execute some external commands
before starting the server, such as creating a directory. If you add
a file named <b>t/<em>test_name-master</em>.sh</b>, it will
be executed by @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl"
before it starts the server; a similar file may be created for the
slave in replication tests.
Because the <b>.sh</b> file is executed through <b>/bin/sh</b>, it
cannot be used on Windows, and any tests using such a file will
automatically be skipped if you run on Windows. For this reason,
this mechanism may be replaced with a more portable one in some
future release of MySQL.
*/
###############################################################################
## Specifying Test Case-Specific Bootstrap Options
/**
@page PAGE_TESTCASE_SPECIFIC_BOOTSTRAP_OPTIONS Specifying Test Case-Specific Bootstrap Options
If a test has to run with a particular value of a bootstrap variable
such as <b>`--innodb-page-size`</b> or
<b>`--innodb-data-file-path`</b>, the option can be passed on the
command line while running @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl". For example, consider a test that can only run
with <b>`--innodb-page-size`=8k</b>. The test can be run like this:
@verbatim
shell> ./mysql-test-run.pl test_name_8k --initialize=--innodb-page-size=8k
@endverbatim
This will initialize the data directory with 8k page size, and start the
server with that value.
It is also possible to pass bootstrap options in the
<b>master.opt</b> file of the test, so that the test can run with
the specified value of the bootstrap options without using any
command line arguments. The usage is:
@verbatim
--initialize --innodb-page-size=8k
@endverbatim
or
@verbatim
--initialize=--innodb-page-size=8k
@endverbatim
Specifying bootstrap variables in the opt file is the preferred
method.
Each bootstrap variable must be specified as the value of a
<b>`--initialize`</b> option in the opt file to ensure @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" recognizes that the
variable must be used during server initialization. If there are
bootstrap options in the file, the current data directory is
deleted, and initialized again with the options set in the file. The
server is also started with the bootstrap options passed along with
the other options in the opt file.
Similarly, bootstrap options passed in the <b>slave.opt</b> will be
used to reinitialize the slave server in replication scenarios.
Bootstrap options set in the opt file are passed to the server
first, followed by the server options. So, server start up options
have precedence over bootstrap options, regardless of the order in
which they are set in the opt file.
Note that since the bootstrap options are passed in the opt files,
they have precedence over the command line bootstrap options. So,
if a test has a master.opt file containing <b>`--innodb-page-size`=8k</b>,
and while it is being run, <b>`--innodb-page-size`=4k</b> is passed on
the command line, the test will run with <b>8k</b> page size.
Some tests require the server to be restarted multiple times with
different server options, as well different bootstrap options. In
such cases, the existing data directory is deleted inside the test
and a new data directory is initialized with the bootstrap options.
When the server is started with the bootstrap options after this,
the SQL queries will run with the specified options.
@verbatim
--exec $MYSQLD --no-defaults --initialize-insecure
--lc_messages_dir=$MYSQL_SHAREDIR --innodb_page_size=8K
--basedir=$MYSQLD_BASEDIR --datadir=$MYSQL_TMP_DIR/datadir1/data
--init-file=$BOOTSTRAP_SQL --secure-file-priv=""
@endverbatim
*/
###############################################################################
## Specifying Test Case-Specific Client Options
/**
@page PAGE_TESTCASE_SPECIFIC_CLIENT_OPTIONS Specifying Test Case-Specific Client Options
If a test case needs a specific client option, you can specify such
options in a file named <b><em>testname</em>-client.opt</b>. When a
test case has its own <b>-client.opt</b> file, @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" examines it for any
additional options that the @ref PAGE_MYSQLTEST "mysqltest" should
run with while executing the test case.
For example, consider a test case <b>example.test</b> needs
<tt>latin1</tt> as default character set for client and connection,
then that option can be specified in
<b><em>example</em>-client.opt</b> file.
@verbatim
--default-character-set=latin1
@endverbatim
You may refer to environment variables in the option file, using the
usual <b><em>$VAR_NAME</em></b> syntax. It is also possible to refer
to optional variables using the syntax <b><em>$?VAR_NAME</em></b>.
This will be replaced with an empty string if the variable is not
set.
*/
###############################################################################
## Using Include Files to Simplify Test Cases
/**
@page PAGE_INCLUDE_FILES Using Include Files to Simplify Test Cases
The <b>include</b> directory contains many files intended for
inclusion into test case files.
These include files serve many purposes, but in general, they
encapsulate operations of varying complexity into single files so
that you can perform each operation in a single step. Include files
are available for operations such as these:
<ul>
<li>
Ensure that a given feature is available. The file checks to
make sure that the feature is available and exits if not.
</li>
<ul>
<li>
Storage engine tests: These files have names of the form
<b>have_<em>engine_name.inc</em></b>, such as
<b>have_archive.inc</b> or <b>have_blackhole.inc</b>. The
<b>MyISAM</b>, <b>MERGE</b>, and <b>MEMORY</b> storage
engines are always supported and need not be checked.
</li>
<li>
Windows specific tests: Include <b>have_windows.inc</b> file
if a test runs only on windows machines.
</li>
<li>
Debugging capabilities: Include the <b>have_debug.inc</b>
file if a test requires that the server was built for
debugging (that is, that the MySQL distribution was configured
with the <b>`--with-debug`</b> option).
</li>
</ul>
<li>
Wait for a condition to become true. Set the
<b>$wait_condition</b> variable to an SQL statement that
selects a value and then include the <b>wait_condition.inc</b>
file. The include file executes the statement in a loop with a
0.1 second sleep between executions until the select value is
nonzero. For example:
@verbatim
--let $wait_condition= SELECT c = 3 FROM t
--source include/wait_condition.inc
@endverbatim
</li>
<li>
Control the binary log format. See @ref PAGE_BINARY_LOG_FORMAT.
</li>
<li>
Control replication slave servers. See @ref
PAGE_WRITING_REPLICATION_TESTS.
</li>
</ul>
You can think of an include file as a rudimentary form of subroutine
that is “called” at the point of inclusion. You can “pass
parameters” by setting variables before including the file and
referring to them within the file. You can “return” values by
setting variables within the file and referring them following
inclusion of the file.
*/
###############################################################################
## Controlling the Binary Log Format Used for Tests
/**
@page PAGE_BINARY_LOG_FORMAT Controlling the Binary Log Format Used for Tests
<h3>Table of Contents</h3>
- @subpage PAGE_CONTROLLING_BINARY_LOG_FORMAT
- @subpage PAGE_SPECIFY_BINARY_LOG_FORMAT
The server can do binary logging using statement-based logging
(SBL), which logs events as statements that produce data changes, or
row-based logging (RBL), which logs events as changes to individual
rows. It also supports mixed logging, which switches between SBL and
RBL automatically as necessary.
The server's global <b>binlog_format</b> system variable indicates
which log format is in effect. It has possible values of
<b>STATEMENT</b>, <b>ROW</b>, and <b>MIXED</b> (not case
sensitive). This system variable can be set at server startup by
specifying <b>`--binlog_format`=<em>value</em></b> on the
command line or in an option file. A user who has the <b>SUPER</b>
privilege can change the log format at runtime. For example:
@verbatim
SET GLOBAL binlog_format = STATEMENT;
@endverbatim
Some tests require a particular binary log format. You can exercise
control over the binary log format in two ways:
- To control the log format that the server uses for an entire
test run, you can pass options to @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl" that tell it which format <b>mysqld</b>
should use.
- To verify that a particular log format is in effect for a specific
test case, you can use an appropriate include file that checks
the current format and exits if the format is other than what
is required.
The following sections describe how to use these techniques.
*/
###############################################################################
## Controlling the Binary Log Format Used for an Entire Test Run
/**
@page PAGE_CONTROLLING_BINARY_LOG_FORMAT Controlling the Binary Log Format Used for an Entire Test Run
To specify the binary log format for a test run, you can use the
<b>`--mysqld`</b> or <b>`--combination`</b> option to tell @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" to pass a logging option
to <b>mysqld</b>. For example, the following command runs the tests
from the <b>rpl</b> suite that have names that begin with
<b>rpl_row</b>. The tests are run once with the binary log format
set to <b>STATEMENT</b>:
@verbatim
shell> ./mysql-test-run.pl --suite=rpl --do-test=rpl_row
--mysqld=--binlog_format=statement
@endverbatim
To run tests under multiple log formats, use two or more instances
of the <b>`--combination`</b> option. The following command runs
the same tests as the preceding command, but runs them once with the
binary log format set to <b>ROW</b> and a second time with the
format set to <b>MIXED</b>:
@verbatim
shell> ./mysql-test-run.pl --suite=rpl --do-test=rpl_row
--combination=--binlog_format=row
--combination=--binlog_format=mixed
@endverbatim
The <b>`--combination`</b> option must be given at least twice or
it has no effect.
As an alternative to using the <b>`--combination`</b> option, you
can create a file named <b>combinations</b> in the test suite
directory and list the options that you would specify using
<b>`--combination`</b>, one line per option. For the preceding
@ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" command, the suite
name is <b>rpl</b>, so you would create a file named
<b>suite/rpl/combinations</b> with these contents:
@verbatim
[row]
--binlog_format=row
[mixed]
--binlog_format=mixed
@endverbatim
Then invoke @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" like this:
@verbatim
shell> ./mysql-test-run.pl --suite=rpl --do-test=row
@endverbatim
Similar to <b>combinations</b> file in the test suite directory, you
can also create a file named <b><em>test_name</em>.combinations</b>
in the test directory and list the options that you would specify
using <b>`--combination`</b>, one line per option.
If there exist both suite level <b>combinations</b> file and a
<b><em>test_name</em>.combinations</b> file, then the
<b><em>test_name</em>.combinations</b> file will take the priority
i.e combinations specified in suite level <b>combinations</b> file
will be ignored.
The format of the <b>combinations</b> file is similar to that of
<b>my.cnf</b> files (section names followed by options for each
section). @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" displays
the section name following the test name when it reports the test
result.
Any <b>`--combination`</b> options specified on the command line
override those found in a <b>combinations</b> file.
The <b>`--combination`</b> option and the <b>combinations</b>
file have different scope. The <b>`--combination`</b> option
applies globally to all tests run by a given invocation of @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl". The
<b>combinations</b> file is placed in a test suite directory and
applies only to tests in that suite. The
<b><em>test_name</em>.combinations</b> file is placed in a test
directory and applies only to <b>test_name</b>.
*/
###############################################################################
## Specifying the Required Binary Log Format for Individual Test Cases
/**
@page PAGE_SPECIFY_BINARY_LOG_FORMAT Specifying the Required Binary Log Format for Individual Test Cases
To specify within a test case that a particular binary log format is
required, include one of the following lines to indicate the format:
@verbatim
--source include/have_binlog_format_row.inc
--source include/have_binlog_format_statement.inc
--source include/have_binlog_format_mixed.inc
@endverbatim
The following files can be used for tests that support two binary
log formats:
@verbatim
--source include/have_binlog_format_mixed_or_row.inc
--source include/have_binlog_format_mixed_or_statement.inc
--source include/have_binlog_format_row_or_statement.inc
@endverbatim
Before @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" runs the test
case, it checks whether the value that it is using for the
<b>binlog_format</b> system variable matches what the test
requires, based on whether the test refers to one of the preceding
include files. If <b>binlog_format</b> does not have an
appropriate value, @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl"
skips the test.
If a test supports all binary log formats, none of the
<b>have_binlog_format_*.inc</b> include files should be used in
the test file. A test that includes no such file is assumed to
support all formats.
*/
###############################################################################
## Writing Replication Tests
/**
@page PAGE_WRITING_REPLICATION_TESTS Writing Replication Tests
If you are writing a replication test case, the test case file
should begin with this command:
@verbatim
--source include/master-slave.inc
@endverbatim
To switch between the master and slave, use these commands:
@verbatim
connection master;
connection slave;
@endverbatim
If you need to do something on an alternative connection, you can
use <b>connection master1;</b> for the master and <b>connection
slave1;</b> for the slave.
To run the master with additional options for your test case, put
them in command-line format in
<b>t/<em>test_name-master</em>.opt</b>. When a file named
<b>t/<em>test_name-master</em>.opt</b> exists, @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" examines it for extra
options that the server needs to be run with when executing the
<em>test_name</em> test case. If no server has yet been started
or the current server is running with different options, @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" restarts the server with
the new options.
For the slave, similar principles apply, but you should list
additional options in <b>t/<em>test_name-slave</em>.opt</b>.
Several include files are available for use in tests that enable
better control over the behavior of slave server I/O and SQL
threads. The files are located in the <b>include</b> directory and
have names of the form <b>wait_for_slave_*.inc</b>. By using these
files, you can help make replication tests more stable because it
will be more likely that test failures are due to replication
failures, not due to problems with the tests themselves.
The slave-control include files address the issue that it is not
always sufficient to use a <b>START SLAVE</b> or <b>STOP
SLAVE</b> statement by itself: When the statement returns, the
slave may not have reached the desired operational state. For
example, with <b>START SLAVE</b>, the following considerations
apply:
<ul>
<li>
It is not necessary to wait for the SQL thread after <b>START
SLAVE</b> or <b>START SLAVE SQL_THREAD</b> because the thread
will have started by the time statement returns.
</li>
<li>
By contrast, it is necessary to wait for the I/O thread after
<b>START SLAVE</b> or <b>START SLAVE IO_THREAD</b> because
although the thread will have started when the statement returns,
it may not yet have established the connection to the master.
</li>
</ul>
To verify that a slave has reached the desired state, combine the
use of <b>START SLAVE</b> or <b>STOP SLAVE</b> with an
appropriate “wait” include file. The file contains code that waits
until the state has been reached or a timeout occurs. For example,
to verify that both slave threads have started, do this:
@verbatim
START SLAVE
--source include/wait_for_slave_to_start.inc
@endverbatim
Similarly, to stop both slave threads, do this:
@verbatim
STOP SLAVE;
--source include/wait_for_slave_to_stop.inc
@endverbatim
The following list describes the include files that are available
for slave control:
<ul>
<li>
<tt>wait_for_slave_to_start.inc</tt>
Waits for both slave threads (I/O and SQL) to start. Should be
preceded by a <b>START SLAVE</b> statement.
</li>
<li>
<tt>wait_for_slave_to_stop.inc</tt>
Waits for both slave threads (I/O and SQL) to stop. Should be
preceded by a <b>STOP SLAVE</b> statement.
</li>
<li>
<tt>wait_for_slave_sql_to_stop.inc</tt>
Waits for the slave SQL thread to stop. Should be preceded by
a <b>STOP SLAVE SQL_THREAD</b> statement.
</li>
<li>
<tt>wait_for_slave_io_to_stop.inc</tt>
Waits for the slave I/O thread to stop. Should be preceded by
a <b>STOP SLAVE IO_THREAD</b> statement.
</li>
<li>
<tt>wait_for_slave_param.inc</tt>
Waits until <b>SHOW SLAVE STATUS</b> output contains a given
value or a timeout occurs. Before including the file, you should
set the <b>$slave_param</b> variable to the column name to
look for in <b>SHOW SLAVE STATUS</b> output, and
<b>$slave_param_value</b> to the value that you are waiting
for the column to have.
Example:
@verbatim
--let $slave_param= Slave_SQL_Running
--let $slave_param_value= No
--source include/slave_wait_slave_param.inc
@endverbatim
</li>
<li>
<tt>wait_for_slave_sql_error.inc</tt>
Waits until the SQL thread for the current connection has gotten
an error or a timeout occurs. Occurrence of an error is
determined by waiting for the <b>Last_SQL_Errno</b> column of
<b>SHOW SLAVE STATUS</b> output to have a nonzero value.
</li>
</ul>
*/
###############################################################################
## Thread Synchronization in Test Cases
/**
@page PAGE_THREAD_SYNCHRONIZATION Thread Synchronization in Test Cases
The Debug Sync facility allows placement of synchronization points
in the code. They can be activated by statements that set the
<b>debug_sync</b> system variable. An active synchronization point
can emit a signal or wait for a signal to be emitted by another
thread. This waiting times out after 300 seconds by default. The
<b>`--debug-sync-timeout`=<em>N</em></b> option for
@ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" changes that
timeout to <b><em>N</em></b> seconds. A timeout of zero disables
the facility altogether, so that synchronization points will not
emit or wait for signals, even if activated.
The purpose of the timeout is to avoid a complete lockup in test
cases. If for some reason the expected signal is not emitted by
any thread, the execution of the affected statement will not block
forever. A warning shows up when the timeout happens. That makes a
difference in the test result so that it will not go undetected.
For test cases that require the Debug Sync facility, include the
following line in the test case file:
@verbatim
--source include/have_debug_sync.inc
@endverbatim
For a description of the Debug Sync facility and how to use
synchronization points,
see [MySQL Internals: Test Synchronization]
(https://dev.mysql.com/doc/internals/en/test-synchronization.html).
*/
###############################################################################
## Suppressing Errors and Warning
/**
@page PAGE_SUPPRESSING_ERRORS_WARNINGS Suppressing Errors and Warning
After a test is finished, and if it didn't fail for some other
reason, @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" will check
the log written by the server(s) during the test for any warnings or
errors. If it finds any, it will print them out and the test will be
reported as failed.
However, many warnings and also a few errors may occur normally
without signifying a real problem. Also, many tests purposefully
perform actions that will provoke warnings. For these not to result
in a test failure, it is possible to specify that certain messages
are to be suppressed.
There is a list of global suppressions; warnings that will always be
suppressed. These are listed in the file
<b>include/mtr_warnings.sql</b>. Any error or warning that
contains one of the listed strings will be ignored. It is not
necessary to include the whole text, and regular expressions can be
used, such as <b>.*</b> to match any substring or <b>[0-9]*</b>
to match any number.
You will rarely need to change or add to this global list, but you
may need to suppress a particular error or warning for a new test
case. A typical case is a test that performs some illegal action on
purpose to test the respone; if this also results in a warning in
the server log, this should not cause this particular test to fail.
To add a suppresion for a warning text like for example <b>The
table 't23456' is full</b> where the number in the table name can
vary, add this line anywhere in the test case file:
@verbatim
call mtr.add_suppression("The table 't[0-9]*' is full");
@endverbatim
This may be put anythere in the test, but we recommend putting it
either near the top, or just after the action that may result in the
warning. If you're adding this line to an existing test, keep in
mind that it will be echoed in the output, so the exact same line
also needs to be added to the corresponding place in the result
file. Alternatively, you may turn off logging like this, and will
then not have to edit the result file:
@verbatim
--disable_query_log
call mtr.add_suppression("The table 't[0-9]*' is full")
--enable_query_log
@endverbatim
It is also possible to intruct @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl" to skip the check for errors and warnings
completely, by use of the <b>`--nowarnings`</b> command line
option.
*/
###############################################################################
## Stopping and restarting a Server During a Test
/**
@page PAGE_STOPPING_AND_RESTARTING_SERVER_DURING_TEST Stopping and Restarting a Server During a Test
If a server dies during execution of a test case, this will be
interpreted as a failure. However, there may be cases where you
actually want to stop and possibly restart a server intentionally.
It is possible to let the system know you expect a server to
terminate, and to either wait or have it restarted immediately:
Before you initiate the action that will stop the server, the test
case should write either <b>restart</b> or <b>wait</b> to the
file <b>$MYSQLTEST_VARDIR/tmp/mysqld.1.expect</b>. The easiest way
to do this is using the <b>exec echo</b> construct like in the
following example.
If you write <b>restart</b> into this file, the server will be
immediately restarted. If you write <b>wait</b> instead, the
server will remain down, but can be restarted at a later time by
writing <b>restart</b> to the file.
@verbatim
--exec echo "wait" > $MYSQLTEST_VARDIR/tmp/mysqld.1.expect
--shutdown_server 10
--source include/wait_until_disconnected.inc
# Do something while server is down
--enable_reconnect
--exec echo "restart" > $MYSQLTEST_VARDIR/tmp/mysqld.1.expect
--source include/wait_until_connected_again.inc
@endverbatim
The file name to write the command to will be
<b>mysqld.2.expect</b> for the slave server in replication tests.
Note that you have to use <b>$MYSQLTEST_VARDIR/tmp</b> for the
directory here; if you use <b>$MYSQL_TMP_DIR</b> instead, it will
not work when running tests in parallel.
For your convenience, there are files which can be used to do
what's shown in the example.
<ul>
<li>
<tt>restart_mysqld.inc</tt>
<b>include/restart_mysqld.inc</b> can be sourced in your
own test case, to shutdown and start the server but
the server is immediately started up again.
@verbatim
# Restart the server
--source include/restart_mysqld.inc
@endverbatim
It is also possible to provide additional command line options
to the restarted server, by writing a line with <b>restart:</b>
(with a colon) followed by one or more options into the expect
file. These extra options will be dropped if the same server
is restarted again, unless they are repeated. A value for
shutdown timeout can also be set with
<b>$shutdown_server_timeout</b>, when this file is used.
@verbatim
# Restart server with extra parameters
--let $shutdown_server_timeout= 10
--let $restart_parameters= "restart: --innodb_autoinc_lock_mode=1"
--source include/restart_mysqld.inc
@endverbatim
</li>
<li>
<tt>kill_and_restart_mysqld.inc</tt>
Similar to <b>include/restart_mysqld.inc</b>,
<b>include/kill_and_restart_mysqld.inc</b> can be used to
restart the server, but setting <b>$shutdown_server_timeout</b>
will have no effect.
@verbatim
# Restart server with extra parameters
--let $restart_paramters= "restart: --innodb_autoinc_lock_mode=0"
--source include/kill_and_restart_mysqld.inc
@endverbatim
</li>
<li>
<tt>shutdown_mysqld.inc and start_mysqld.inc</tt>
If there is something to be done between the server shutdown
and startup, there is a file
<b>include/shutdown_mysqld.inc</b>
which can be used to shutdown the server. A shutdown timeout
value can be set and passed to
<b>include/shutdown_mysqld.inc</b>.
<b>include/start_mysqld.inc</b> can be used to start the
server again after it has been shutdown.
@verbatim
# Timeout of 10 seconds
--let $shutdown_server_timeout= 10
--source include/shutdown_mysqld.inc
# Do something while the server is down
--source include/start_mysqld.inc
@endverbatim
</li>
<li>
<tt>kill_mysqld.inc</tt>
To the kill the server,
<b>include/kill_mysqld.inc</b> can be sourced, which
internally calls <b>--shutdown_server 0</b>. Therefore,
setting a value for shutdown timeout will have no effect.
@verbatim
--source include/kill_mysqld.inc
# Do something while the server is down
--source include/start_mysqld.inc
@endverbatim
</li>
<li>
<tt>wait_until_disconnected.inc</tt>
It is recommended to use <b>include/wait_until_disconnected</b>
in tandem with <b>--shutdown_server</b>. It ensures that all
connections to the server are dropped before proceeding with
the test. This file is sourced internally in
<b>include/shutdown_mysqld.inc</b>,
<b>include/kill_mysqld.inc</b>,
<b>include/kill_and_restart_mysqld.inc</b>,
and <b>include/restart_mysqld.inc</b>.
</li>
<li>
<tt>wait_until_connected_again.inc</tt>
<b>include/wait_until_connected_again.inc</b> is used after
the server is started again, to ensure that the client
connection is restored. It tries to establish the connection
till a timeout occurs. This file is sourced internally in
<b>include/start_mysqld.inc</b>,
<b>include/restart_mysqld.inc</b>,
and <b>include/kill_and_restart_mysqld.inc</b>.
</li>
</ul>
*/
###############################################################################
## Other Tips for Writing Test Cases
/**
@page PAGE_TIPS_WRITING_TESTCASES Other Tips for Writing Test Cases
<ul>
<li>
Writing loops
If you need to do something in a loop, you can use something like this:
@verbatim
let $1= 10;
while ($1)
{
# execute your statements here
dec $1;
}
@endverbatim
</li>
<li>
Pausing between statements
To sleep between statements, use the <b>sleep</b> command. It
supports fractions of a second. For example, <b>sleep 0.2</b>;
sleeps 0.2 seconds.
Try not to use <b>sleep</b> or <b>real_sleep</b> commands
more than necessary. The more of them there are, the slower the
test suite becomes. In some cases, heavy reliance on sleep
operations is an indicator that the logic of a test should be
reconsidered.
</li>
<li>
Commenting the test result
When the output in a result file is not understandable by
inspection, it can be helpful to have the test case write
comments to the result file that provide context. You can use
the <b>echo</b> command for this:
@verbatim
--echo # Comment to explain the following output
@endverbatim
Of course, the same line (without <b>`--echo`</b>) will need
to be put in the corresponding place in the result file, if you
are adding this to an existing test.
</li>
<li>
Sorting result sets
If a test case depends on <b>SELECT</b> output being in a
particular row order, use an <b>ORDER BY</b> clause. Do not
assume that rows will be selected in the same order they are
inserted, particularly for tests that might be run multiple
times under conditions that can change the order, such as with
different storage engines, or with and without indexing.
If you do not want to add <b>ORDER BY</b> to the query, an
alternative is to use the test command <b>sorted_result</b>
which will sort the result of the following statement before
putting it into the result file.
</li>
<li>
Performing file system operations
Avoid using <b>exec</b> or <b>system</b> to execute
operating system commands for file system operations. This used
to be very common, but OS commands tend to be platform specific,
which reduces test portability. @ref PAGE_MYSQLTEST "mysqltest"
now has several commands to perform these operations portably,
so these commands should be used instead: <b>remove_file</b>,
<b>chmod</b>, <b>mkdir</b>, and so forth.
</li>
<li>
Local versus remote storage
Some test cases depend on being run on local storage, and may
fail when run on remote storage such as a network share. For
example, if the test result can be affected by differences
between local and remote file system times, the expected result
might not be obtained. Failure of these test cases under such
circumstances does not indicate an actual malfunction. It is not
generally possible to determine whether tests are being run on
local storage.
</li>
<li>
Skipping consistency check or forcing restart after test
As mentioned before, a test case should leave the server in a
"clean" state for the next test. In cases where this is not
possible or too costly, the test may in stead ask for the
consistency check to be skipped, and the server(s) to be
restarted. This is done by this executing this command at any
time during the test:
@verbatim
call mtr.force_restart();
@endverbatim
This signals to @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl"
that it should restart the server before the next test, and also
skip the consistency check.
</li>
</ul>
*/
###############################################################################
## MySQL Test Programs
/**
@page PAGE_MYSQLTEST_PROGRAMS MySQL Test Programs
<h3>Table of Contents</h3>
- @subpage PAGE_MYSQLTEST
- @subpage PAGE_MYSQL_CLIENT_TEST
- @subpage PAGE_MYSQL_TEST_RUN_PL
- @subpage PAGE_MYSQL_STRESS_TEST_PL
This chapter describes the test programs that run test cases. For
information about the language used for writing test cases, see @ref
PAGE_MYSQLTEST_LANGUAGE_REFERENCE.
The test suite uses the following programs:
<ul>
<li>
The @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" Perl script
is the main application used to run the MySQL test suite. It
invokes @ref PAGE_MYSQLTEST "mysqltest" to run individual test
cases. (Prior to MySQL 4.1, a similar shell script,
<b>mysql-test-run</b>, can be used instead).
</li>
<li>
@ref PAGE_MYSQLTEST "mysqltest" runs test cases.
</li>
<li>
The @ref PAGE_MYSQL_CLIENT_TEST "mysql_client_test" program is
used for testing aspects of the MySQL client API that cannot be
tested using @ref PAGE_MYSQLTEST "mysqltest" and its test
language.
</li>
<li>
The @ref PAGE_MYSQL_STRESS_TEST_PL "mysql-stress-test.pl" Perl
script performs stress-testing of the MySQL server.
</li>
</ul>
*/
###############################################################################
## mysqltest — Program to Run Test Cases
/**
@page PAGE_MYSQLTEST mysqltest — Program to Run Test Cases
The @ref PAGE_MYSQLTEST "mysqltest" program runs a test case against
a MySQL server and optionally compares the output with a result
file. This program reads input written in a special test language.
Typically, you invoke @ref PAGE_MYSQLTEST "mysqltest" using @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" rather than invoking it
directly.
Features of @ref PAGE_MYSQLTEST "mysqltest":
- Can send SQL statements to MySQL servers for execution
- Can execute external shell commands
- Can test whether the result from an SQL statement or shell
command is as expected
- Can connect to one or more standalone <b>mysqld</b> servers
and switch between connections
By default, @ref PAGE_MYSQLTEST "mysqltest" reads the test case on
the standard input. To run @ref PAGE_MYSQLTEST "mysqltest" this way,
you normally invoke it like this:
@verbatim
shell> mysqltest [options] [db_name] < test_file
@endverbatim
You can also name the test case file with a <b>`--test-
file`=<em>file_name</em></b> option.
The exit value from @ref PAGE_MYSQLTEST "mysqltest" is 0 for
success, 1 for failure, and 62 if it skips the test case (for
example, if after checking some preconditions it decides not to
run the test).
@ref PAGE_MYSQLTEST "mysqltest" supports the following options:
<ul>
<li>
<tt>`--help`, -?</tt>
Display a help message and exit.
</li>
<li>
<tt>`--async-client`</tt>
Enable asynchronous communication support in mysql protocol.
</li>
<li>
<tt>`--basedir`=<b>dir_name</b>, -b <b>dir_name</b></tt>
The base directory for tests.
</li>
<li>
<tt>`--character-sets-dir`=<b>path</b></tt>
The directory where character sets are installed.
</li>
<li>
<tt>`--colored-diff`</tt>
Colorize the diff part of the output.
If enabled, @ref PAGE_MYSQLTEST "mysqltest" uses <b>diff</b>
command with <b>`--color`='always'</b> option to print the
colored diff. If the command fails or is not supported, @ref
PAGE_MYSQLTEST "mysqltest" will report an error and abort the
test run.
@note
<b>`--color`</b> option for <b>diff</b> command is available
from <b>GNU diffutils</b> version <b>3.4</b>.
</li>
<li>
<tt>`--compress`, -C</tt>
Compress all information sent between the client and the server
if both support compression.
</li>
<li>
<tt>`--cursor-protocol`</tt>
Use cursors for prepared statements.
</li>
<li>
<tt>`--database`=<b>db_name</b>, -D <b>db_name</b></tt>
The default database to use.
</li>
<li>
<tt>`--debug`[=<b>debug_options</b>], -#[<b>debug_options</b>]</tt>
Write a debugging log if MySQL is built with debugging support.
The default <b><em>debug_options</em></b> value is
<b>'d:t:S:i:O,/tmp/mysqltest.trace'</b>.
</li>
<li>
<tt>`--debug-check`</tt>
Print some debugging information when the program exits.
</li>
<li>
<tt>`--debug-info`</tt>
Print debugging information and memory and CPU usage statistics
when the program exits.
</li>
<li>
<tt>`--default-character-set`=<b>charset_name</b></tt>
Use <b>charset_name</b> as the default character set for the
client and connection. For more information, see [Connection
Character Sets and Collations]
(https://dev.mysql.com/doc/refman/8.0/en/charset-connection.html).
</li>
<li>
<tt>`--explain-protocol`</tt>
Run <b>EXPLAIN EXTENDED</b> on all <b>SELECT</b>,
<b>INSERT</b>, <b>REPLACE</b>, <b>UPDATE</b> and
<b>DELETE</b> queries.
</li>
<li>
<tt>`--host`=<b>host_name</b>, -h <b>host_name</b></tt>
Connect to the MySQL server on the given host.
</li>
<li>
<tt>`--include`=<b>file_name</b>, -i <b>file_name</b></tt>
Include the contents of the given file before processing the
contents of the test file. The included file should have the
same format as other @ref PAGE_MYSQLTEST "mysqltest" test files.
This option has the same effect as putting a <b>`--source`
<em>file_name</em></b> command as the first line of the test
file.
</li>
<li>
<tt>`--json-explain-protocol`</tt>
Run <b>EXPLAIN EXTENDED</b> on all <b>SELECT</b>,
<b>INSERT</b>, <b>REPLACE</b>, <b>UPDATE</b> and
<b>DELETE</b> queries. The <b>json-explain-protocol</b>
</li>
<li>
<tt>`--logdir`=<b>dir_name</b></tt>
The directory to use for log files.
</li>
<li>
<tt>`--mark-progress`</tt>
Write the line number and elapsed time to
<b><em>test_file</em>.progress.</b>
</li>
<li>
<tt>`--max-connect-retries`=<b>num</b></tt>
The maximum number of connection attempts when connecting to
server.
</li>
<li>
<tt>`--max-connections`=<b>num</b></tt>
The maximum number of simultaneous server connections per client
(that is, per test). If not set, the maximum is 128. Minimum
allowed limit is 8, maximum is 5120.
</li>
<li>
<tt>`--no-defaults`</tt>
Do not read default options from any option files. If used, this
must be the first option.
</li>
<li>
<tt>`--plugin-dir`=<b>path</b></tt>
The directory in which to look for plugins. It may be necessary
to specify this option if the <b><em>default_auth</em></b>
argument is used for the <b>connect()</b> command to specify
an authentication plugin but @ref PAGE_MYSQLTEST "mysqltest"
does not find it.
</li>
<li>
<tt>`--password`[=<b>password</b>], -p[<b>password</b>]</tt>
The password to use when connecting to the server. If you use
the short option form (<b>-p</b>), you <b><em>cannot</em></b>
have a space between the option and the password. If you omit
the <b><em>password</em></b> value following the
<b>`--password`</b> or <b>-p</b> option on the command line,
you are prompted for one.
</li>
<li>
<tt>`--port`=<b>port_num</b>, -P <b>port_num</b></tt>
The TCP/IP port number to use for the connection.
</li>
<li>
<tt>`--protocol`={TCP|SOCKET|PIPE|MEMORY}</tt>
Choose the protocol for communication with the server.
<b>SOCKET</b> is default.
</li>
<li>
<tt>`--ps-protocol`</tt>
Use the prepared-statement protocol for communication.
</li>
<li>
<tt>`--quiet`</tt>
Suppress all normal output. This is a synonym for
<b>`--silent`</b>.
</li>
<li>
<tt>`--record`, -r</tt>
Record the output that results from running the test file into
the file named by the <b>`--result-file`</b> option, if that
option is given. It is an error to use this option without also
using <b>`--result-file`</b>.
</li>
<li>
<tt>`--result-file`=<b>file_name</b>, -R <b>file_name</b></tt>
This option specifies the file for test case expected results.
<b>`--result-file`</b>, together with <b>`--record`</b>,
determines how @ref PAGE_MYSQLTEST "mysqltest" treats the test
actual and expected results for a test case:
<ul>
<li>
If the test produces no results, @ref PAGE_MYSQLTEST
"mysqltest" exits with an error message to that effect,
unless <b>`--result-file`</b> is given and the named file
is an empty file.
</li>
<li>
Otherwise, if <b>`--result-file`</b> is not given, @ref
PAGE_MYSQLTEST "mysqltest" sends test results to the
standard output.
</li>
<li>
With <b>`--result-file`</b> but not <b>`--record`</b>,
@ref PAGE_MYSQLTEST "mysqltest" reads the expected results
from the given file and compares them with the actual
results. If the results do not match, @ref PAGE_MYSQLTEST
"mysqltest" writes a <b>.reject</b> file in the log
directory, outputs a diff of the two files, and exits with
an error.
</li>
<li>
With both <b>`--result-file`</b> and <b>`--record`</b>,
@ref PAGE_MYSQLTEST "mysqltest" updates the given file by
writing the actual test results to it.
</li>
</ul>
</li>
<li>
<tt>`--server-public-key-path`=<b>file_name</b></tt>
The path name to a file containing the server RSA public key.
The file must be in PEM format. The public key is used for RSA
encryption of the client password for connections to the server
made using accounts that authenticate with the
<b>sha256_password</b> plugin. This option is ignored for
client accounts that do not authenticate with that plugin. It is
also ignored if password encryption is not needed, as is the
case when the client connects to the server using an SSL
connection.
The server sends the public key to the client as needed, so it
is not necessary to use this option for RSA password encryption
to occur. It is more efficient to do so because then the server
need not send the key.
For additional discussion regarding use of the
<b>sha256_password plugin</b>, including how to get the RSA
public key, see [The SHA-256 Authentication Plugin]
(https://dev.mysql.com/doc/refman/8.0/en/sha256-authentication-plugin.html).
</li>
<li>
<tt>`--silent`, -s</tt>
Suppress all normal output.
</li>
<li>
<tt>`--skip-safemalloc`</tt>
Do not use memory allocation checking.
</li>
<li>
<tt>`--sleep`=<b>num</b>, -T <b>num</b></tt>
Cause all <b>sleep</b> commands in the test case file to sleep
<b><em>num</em></b> seconds. This option does not affect
<b>real_sleep</b> commands.
An option value of 0 can also be used, which effectively
disables <b>sleep</b> commands in the test case.
</li>
<li>
<tt>`--socket`=<b>path</b>, -S <b>path</b></tt>
The socket file to use when connecting to <b>localhost</b>
(which is the default host).
</li>
<li>
<tt>`--sp-protocol`</tt>
Execute DML statements within a stored procedure. For every DML
statement, @ref PAGE_MYSQLTEST "mysqltest" creates and invokes a
stored procedure that executes the statement rather than
executing the statement directly.
</li>
<li>
<tt>`--tail-lines`=<b>n</b></tt>
Specify how many lines of the result to include in the output if
the test fails because an SQL statement fails. The default is 0,
meaning no lines of result printed.
</li>
<li>
<tt>`--test-file`=<b>file_name</b>, -x <b>file_name</b></tt>
Read test input from this file. The default is to read from the
standard input.
</li>
<li>
<tt>`--timer-file`=<b>file_name</b>, -m <b>file_name</b></tt>
If given, the number of millisecond spent running the test will
be written to this file. This is used by @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" for its reporting.
</li>
<li>
<tt>`--tls-version`=<b>protocol_list</b></tt>
The protocols permitted by the client for encrypted connections.
The value is a comma-separated list containing one or more of
these protocols: TLSv1, TLSv1.1, TLSv1.2.
</li>
<li>
<tt>`--tmpdir`=<b>dir_name</b>, -t <b>dir_name</b></tt>
The temporary directory where socket files are created.
</li>
<li>
<tt>`--trace-exec`</tt>
If enabled, this option causes @ref PAGE_MYSQLTEST "mysqltest"
to immediately display the output from executed programs to
stdout.
</li>
<li>
<tt>`--user`=<b>user_name</b>, -u <b>user_name</b></tt>
The MySQL user name to use when connecting to the server.
</li>
<li>
<tt>`--verbose, -v`</tt>
Verbose mode. Print out more information about what the program
does.
</li>
<li>
<tt>`--version, -V`</tt>
Display version information and exit.
</li>
<li>
<tt>`--view-protocol`</tt>
Every <b>SELECT</b> statement is wrapped inside a view.
</li>
</ul>
*/
###############################################################################
## mysql_client_test — Test Client API
/**
@page PAGE_MYSQL_CLIENT_TEST mysql_client_test — Test Client API
The @ref PAGE_MYSQL_CLIENT_TEST "mysql_client_test" program is used
for testing aspects of the MySQL client API that cannot be tested
using @ref PAGE_MYSQLTEST "mysqltest" and its test language. @ref
PAGE_MYSQL_CLIENT_TEST "mysql_client_test" is run as part of the
test suite.
The source code for the programs can be found in in
<b>tests/mysql_client_test.c</b> in a source distribution. The
program serves as a good source of examples illustrating how to use
various features of the client API.
@ref PAGE_MYSQL_CLIENT_TEST "mysql_client_test" is used in a test by
the same name in the main tests suite of @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl" but may also be run directly. Unlike the other
programs listed here, it does not read an external description of
what tests to run. Instead, all tests are coded into the program,
which is written to cover all aspects of the C language API.
@ref PAGE_MYSQL_CLIENT_TEST "mysql_client_test" supports the
following options:
<ul>
<li>
<tt>`--help`, -?</tt>
Display a help message and exit.
</li>
<li>
<tt>`--basedir`=<b>dir_name</b>, -b <b>dir_name</b></tt>
The base directory for the tests.
</li>
<li>
<tt>`--count`=<b>count</b>, -t <b>count</b></tt>
The number of times to execute the tests.
</li>
<li>
<tt>`--database`=<b>db_name</b>, -D <b>db_name</b></tt>
The database to use.
</li>
<li>
<tt>`--debug`[=<b>debug_options</b>], -#[<b>debug_options</b>]</tt>
Write a debugging log if MySQL is built with debugging support.
The default <b>debug_options</b> value is
<tt>'d:t:o,/tmp/mysql_client_test.trace'</tt>.
</li>
<li>
<tt>`--getopt-ll-test`=<b>option</b>,
-g <b>option</b></tt>
Option to use for testing bugs in the <tt>getopt</tt> library.
</li>
<li>
<tt>`--host`=<b>host_name</b>, -h <b>host_name</b></tt>
Connect to the MySQL server on the given host.
</li>
<li>
<tt>`--password`[=<b>password</b>], -p[<b>password]</b></tt>
The password to use when connecting to the server. If you use
the short option form (<b>-p</b>), you <tt><em>cannot</em></tt>
have a space between the option and the password. If you omit
the <b>password</b> value following the
<b>`--password`</b> or <b>-p</b> option on the command line,
you are prompted for one.
</li>
<li>
<tt>`--port`=<b>port_num</b>, -P <b>port_num</b></tt>
The TCP/IP port number to use for the connection.
</li>
<li>
<tt>`--show-tests`, -T</tt>
Show all test names.
</li>
<li>
<tt>`--silent`, -s</tt>
Be more silent.
</li>
<li>
<tt>`--socket`=<b>path</b>, -S <b>path</b></tt>
The socket file to use when connecting to <b>localhost</b>
(which is the default host).
</li>
<li>
<tt>`--testcase`, -c</tt>
The option is used when called from @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl", so that @ref PAGE_MYSQL_CLIENT_TEST
"mysql_client_test" may optionally behave in a different way
than if called manually, for example by skipping some tests.
Currently, there is no difference in behavior but the option is
included to make this possible.
</li>
<li>
<tt>`--user`=<b>user_name</b>, -u <b>user_name</b></tt>
The MySQL user name to use when connecting to the server.
</li>
<li>
<tt>`--vardir`=<b>dir_name</b>, -v <b>dir_name</b></tt>
The data directory for tests. The default is
<b>mysql-test/var</b>.
</li>
</ul>
*/
###############################################################################
## mysql-test-run.pl — Run MySQL Test Suite
/**
@page PAGE_MYSQL_TEST_RUN_PL mysql-test-run.pl — Run MySQL Test Suite
The @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" Perl script is
the main application used to run the MySQL test suite. It invokes
@ref PAGE_MYSQLTEST "mysqltest" to run individual test cases.
Invoke @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" in the
<b>mysql-test</b> directory like this:
@verbatim
shell> mysql-test-run.pl [options] [test_name] ...
@endverbatim
Each <b>test_name</b> argument names a test case. The test
case file that corresponds to the test name is
<b>t/<em>test_name</em>.test</b>.
For each <b>test_name</b> argument, @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" runs the named test case.
With no <b>test_name</b> arguments, @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" runs all <b>.test</b>
files in the <b>t</b> subdirectory.
If no suffix is given for the test name, a suffix of <b>.test</b>
is assumed. Any leading path name is ignored. These commands are
equivalent:
@verbatim
shell> mysql-test-run.pl mytest
shell> mysql-test-run.pl mytest.test
shell> mysql-test-run.pl t/mytest.test
@endverbatim
A suite name can be given as part of the test name. That is, the
syntax for naming a test is:
@verbatim
[suite_name.]test_name[.suffix]
@endverbatim
If a suite name is given, @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl" looks in that suite for the test. The test file
corresponding to a test named <b>suite_name.test_name</b> is
found in
<b>suite/<em>suite_name</em>/t/<em>test_name</em>.test</b>.
There is also an implicit suite name <b>main</b> for the tests in
the top <b>t</b> directory. With no suite name, @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" looks in the default list
of suites for a match and runs the test in any suites where it finds
the test. Suppose that the default suite list is <b>main</b>,
<b>binlog</b>, <b>rpl</b>, and that a test <b>mytest.test</b>
exists in the <b>main</b> and <b>rpl</b> suites. With an
argument of <b>mytest</b> or <b>mytest.test</b>, @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" will run
<b>mytest.test</b> from the <b>main</b> and <b>rpl</b> suites.
To run a family of test cases for which the names share a common
prefix, use the <b>`--do-test`=<em>prefix</em></b> option.
For example, <b>`--do-test`=rpl</b> runs the replication tests
(test cases that have names beginning with <b>rpl</b>).
<b>`--skip-test`</b> has the opposite effect of skipping test
cases for which the names share a common prefix.
The argument for the <b>`--do-test`</b> and <b>`--skip-test`</b>
options also allows more flexible specification of which tests to
perform or skip. If the argument contains a pattern metacharacter
other than a lone period, it is interpreted as a Perl regular
expression and applies to test names that match the pattern. If the
argument contains a lone period or does not contain any pattern
metacharacters, it is interpreted the same way as previously and
matches test names that begin with the argument value. For example,
<b>`--do-test`=testa</b> matches tests that begin with testa,
<b>`--do-test`=main.testa</b> matches tests in the <b>main</b>
test suite that begin with <b>testa</b>, and
<b>`--do-test`=main.*testa</b> matches test names that contain
<b>main</b> followed by <b>testa</b> with anything in between.
In the latter case, the pattern match is not anchored to the
beginning of the test name, so it also matches names such as
<b>xmainytesta</b>.
It is also possible to put a list of test names in a file and have
@ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" run those tests,
using the option <b>`--do-test-list`=file</b>. The tests should be
listed one per line in the file. A line beginning with <b>#</b>
indicates a comment and is ignored. Similary an empty line in the
file is also ignored.
@ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" also supports a
<b>`--do-suite`</b> option, which is similar to <b>`--do-test`</b>
but permits specifying entire suites of tests to run.
To perform setup prior to running tests, @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl" needs to invoke <b>mysqld</b> with the
<b>`--initialize`</b> and <b>`--skip-grant-tables`</b> options.
If MySQL was built with the compiler flag
<b>-DDISABLE_GRANT_OPTIONS</b>, then <b>`--initialize`</b>,
<b>`--skip-grant-tables`</b>, and <b>`--init-file`</b> will be
disabled. To handle this, set the <b>MYSQLD_BOOTSTRAP</b>
environment variable to the full path name of a server that has all
options enabled. @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl"
will use that server to perform setup; it is not used to run the
tests.
The <b>init_file</b> test will fail if <b>`--init-file`</b> is
disabled. This is an expected failure in this case.
To run @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" on Windows,
you'll need either Cygwin or ActiveState Perl to run it. You may
also need to install the modules required by the script. To run the
test script, change location into the <b>mysql-test</b> directory,
set the <b>MTR_VS_CONFIG</b> environment variable to the
configuration you selected earlier (or use the <b>`--vs-config`</b>
option), and invoke @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl".
For example (using <b>Cygwin</b> and the <b>bash</b> shell):
@verbatim
shell> cd mysql-test
shell> export MTR_VS_CONFIG=debug
shell> ./mysqltest-run.pl --force --timer
shell> ./mysqltest-run.pl --force --timer --ps-protocol
@endverbatim
@ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" uses several
environment variables. Some of them are listed in the following
table. Some of these are set from the outside and used by @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl", others are set by @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" instead, and may be
referred to in tests.
<table>
<tr>
<th>Variable</th>
<th>Description</th>
</tr>
<tr>
<td><tt>MTR_BUILD_THREAD</tt></td>
<td>
If set, defines which port number range is used for the server
</td>
</tr>
<tr>
<td><tt>MTR_MAX_PARALLEL</tt></td>
<td>
If set, defines maximum number of parallel threads if
<b>`--parallel`=auto</b> is given
</td>
</tr>
<tr>
<td><tt>MTR_MEM</tt></td>
<td>
If set to anything, will run tests with files in "memory"
using tmpfs or ramdisk. Not available on Windows. Same as
<b>`--mem`</b> option
</td>
</tr>
<tr>
<td><tt>MTR_<b>NAME</b>_TIMEOUT</tt></td>
<td>
Setting of a timeout in minutes or seconds, corresponding to
command line option <b>`--name-timeout`</b>. Avaliable timeout
names are <b>TESTCASE</b>, <b>SUITE</b> (both in minutes) and
<b>START</b>, <b>SHUTDOWN</b>, <b>CTEST</b> (all in seconds).
<b>MTR_CTEST_TIMEOUT</b> is for <b>ctest</b> unit tests.
</td>
</tr>
<tr>
<td><tt>MTR_PARALLEL</tt></td>
<td>
If set, defines number of parallel threads executing tests. Same
as <tt>`--parallel`</tt> option
</td>
</tr>
<tr>
<td><tt>MTR_PORT_BASE</tt></td>
<td>
If set, defines which port number range is used for the server
</td>
</tr>
<tr>
<td><tt>MTR_RECORD</tt></td>
<td>
Set to 1 if a MTR run is started with <b>`--record`</b>
option, 0 otherwise.
</td>
</tr>
<tr>
<td><tt>MTR_UNIQUE_IDS_DIR</tt></td>
<td>
The method in which the free ports are allocated is by maintaining
a list under the unique ids directory. In case there are multiple
chroot environments on the same host, then the same set of ports may
get allocated for all environments, because there will be
multiple unique ids directories in different physical locations,
but MTR assumes it is the same directory.
This will lead to a conflict while reserving ports for the
different MTR runs. To avoid this problem, when using chroot
environments, <b>MTR_UNIQUE_IDS_DIR</b> environment variable can
be set to a common location, so that all the MTR processes will
use the same unique ids directory.
Users have to make sure this variable is set to the same path
on all environments, and that this common path is mounted on
all the environments.
<tr>
<td><tt>MYSQL_CONFIG_EDITOR</tt></td>
<td>
Path name to <b>mysql_config_editor</b> binary.
</td>
</tr>
<tr>
<td><tt>MYSQL_TEST</tt></td>
<td>
Path name to @ref PAGE_MYSQLTEST "mysqltest" binary
</td>
</tr>
<tr>
<td><tt>MYSQL_TEST_DIR</tt></td>
<td>
Full path to the <tt>mysql-test</tt> directory where tests
are being run from
</td>
</tr>
<tr>
<td><tt>MYSQL_TEST_LOGIN_FILE</tt></td>
<td>
Path name to login file used by <b>mysql_config_editor</b>.
If not set, the default is <b>$HOME/.mylogin.cnf</b>, or
<b>\%APPDATA%\\MySQL\\\.mylogin.cnf</b> on Windows.
</td>
</tr>
<tr>
<td><tt>MYSQL_TMP_DIR</tt></td>
<td>
Path to temp directory used for temporary files during tests
</td>
</tr>
<tr>
<td><tt>MYSQLD</tt></td>
<td>
Full path to server executable used in tests.
</td>
</tr>
<tr>
<td><tt>MYSQLD_BOOTSTRAP</tt></td>
<td>
Full path name to <b>mysqld</b> that has all options enabled
</td>
</tr>
<tr>
<td><tt>MYSQLD_BOOTSTRAP_CMD</tt></td>
<td>
Full command line used for initial database setup for this
test batch
</td>
</tr>
<tr>
<td><tt>MYSQLD_CMD</tt></td>
<td>
Command line for starting server as used in tests, with the
minimum set of required arguments.
</td>
</tr>
<tr>
<td><tt>MYSQLTEST_VARDIR</tt></td>
<td>
Path name to the <b>var</b> directory that is used for logs,
temporary files, and so forth
</td>
</tr>
<tr>
<td><tt>NUMBER_OF_CPUS</tt></td>
<td>
Defines number of processors.
</td>
</tr>
<tr>
<td><tt>TSAN_OPTIONS</tt></td>
<td>
Path name to a file containing ThreadSanitizer suppressions.
</td>
</tr>
</table>
The variable <b>MTR_PORT_BASE</b> is a more logical replacement
for the original variable <b>MTR_BUILD_THREAD</b>. It gives the
actual port number directly (will be rounded down to a multiple of
10). If you use <b>MTR_BUILD_THREAD</b>, the port number is found
by multiplying this by 10 and adding 10000.
Tests sometimes rely on certain environment variables being defined.
For example, certain tests assume that <b>MYSQL_TEST</b> is
defined so that @ref PAGE_MYSQLTEST "mysqltest" can invoke itself
with <b>exec $MYSQL_TEST</b>.
Other tests may refer to the last three variables listed in the
preceding table, to locate files to read or write. For example,
tests that need to create files will typically put them in
<b>$MYSQL_TMP_DIR/file_name</b>.
The variable <b>$MYSQLD_CMD</b> will include any server options
added with the <b>`--mysqld`</b> option to @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl", but will not include
server options added specifically for the currently running test.
@ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" supports the
options in the following list. An argument of -- tells @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" not to process any
following arguments as options.
<ul>
<li>
<tt>`--help, -h`</tt>
Display a help message and exit.
</li>
<li>
<tt>`--big-test`</tt>
Allow tests marked as "big" to run. Tests can be thus marked by
including the line <b>`--source` include/big_test.inc</b>, and
they will only be run if this option is given, or if the
environment variable <b>BIG_TEST</b> is set to 1.
This is typically done for tests that take very long to run, or
that use very much resources, so that they are not suitable for
running as part of a normal test suite run.
If both <b>`--big-test`</b> and <b>`--only-big-tests`</b>
are given, <b>`--only-big-tests`</b> is ignored.
@note
This option is enabled by default when test cases are specified
on command line.
</li>
<li>
<tt>`--boot-dbx`</tt>
Run the <b>mysqld</b> server used for bootstrapping the database
through the <b>dbx</b> debugger.
</li>
<li>
<tt>`--boot-ddd`</tt>
Run the <b>mysqld</b> server used for bootstrapping the database
through the <b>ddd</b> debugger.
</li>
<li>
<tt>`--boot-gdb`</tt>
Run the <b>mysqld</b> server used for bootstrapping the database
through the <b>gdb</b> debugger.
See also the <b>`--manual-boot-gdb`</b> option.
</li>
<li>
<tt>`--build-thread`=<b>number</b></tt>
Specify a number to calculate port numbers from. The formula is
<b>10 * build_thread + 10000</b>. Instead of a number, it can
be set to <b>auto</b>, which is also the default value, in
which case @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" will
allocate a number unique to this host.
The value (number or <b>auto</b>) can also be set with the
<b>MTR_BUILD_THREAD</b> environment variable.
This option is kept for backward compatibility. The more logical
<b>`--port-base`</b> is recommended instead.
</li>
<li>
<tt>`--callgrind`</tt>
Instructs <b>valgrind</b> to use <b>callgrind</b>.
</li>
<li>
<tt>`--charset-for-testdb`=<b>charset_name</b></tt>
Specify the default character set for the test database. The
default value is latin1.
</li>
<li>
<tt>`--check-testcases`</tt>
Check test cases for side effects. This is done by checking the
system state before and after each test case. If there is any
difference, the test case is marked as failed because of it.
Similarly, when <b>`--check-testcases`</b> option is enabled,
MTR does additional check for missing <b>.result</b> file and a
test case not having its corresponding <b>.result</b> file is
marked as failed.
This check is enabled by default. To disable it, use the
<b>`--nocheck-testcases`</b> option.
</li>
<li>
<tt>`--clean-vardir`</tt>
Clean up the <b>var</b> directory with logs and test results
etc. after the test run, but only if there were no test
failures. This option only has effect if also running with
option <b>`--mem`</b>. The intent is to alleviate the problem
of using up memory for test results, in cases where many
different test runs are being done on the same host.
</li>
<li>
<tt>`--client-bindir`=<b>path</b></tt>
The path to the directory where client binaries are located.
</li>
<li>
<tt>`--client-dbx`</tt>
Start @ref PAGE_MYSQLTEST "mysqltest" in the <b>dbx</b>
debugger.
</li>
<li>
<tt>`--client-ddd`</tt>
Start @ref PAGE_MYSQLTEST "mysqltest" in the <b>ddd</b>
debugger.
</li>
<li>
<tt>`--client-debugger`=<b>debugger</b></tt>
Start @ref PAGE_MYSQLTEST "mysqltest" in the named debugger.
</li>
<li>
<tt>`--client-gdb`</tt>
Start @ref PAGE_MYSQLTEST "mysqltest" in the <b>gdb</b> debugger.
</li>
<li>
<tt>`--client-libdir`=<b>path</b></tt>
The path to the directory where client libraries are located.
</li>
<li>
<tt>`--colored-diff`</tt>
Colorize the diff part of the output.
When this option is enabled, @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl" passes <b>`--colored-diff`</b> option to
@ref PAGE_MYSQLTEST "mysqltest". If colored diff is enabled,
@ref PAGE_MYSQLTEST "mysqltest" uses <b>diff</b> command with
<b>`--color`='always'</b> option to print the colored diff.
@note
<b>`--color`</b> option for <b>diff</b> command is available
from <b>GNU diffutils</b> version <b>3.4</b>.
</li>
<li>
<tt>`--combination`=<b>value</b></tt>
Extra option to pass to <b>mysqld</b>. The value should consist
of a single <b>mysqld</b> option including dashes. This option
is similar to <b>`--mysqld`</b> but has a different effect.
@ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" executes
multiple test runs, using the options for each instance of
<b>`--combination`</b> in successive runs. If
<b>`--combination`</b> is given only once, it has no effect and
behaves similar to <b>`--mysqld`</b> option.
If a test being run, passes the same <b>`--mysqld`</b> option from an
opt file which is also passed from <b>`--combination`</b>, then that
<b>`--combination`</b> run is skipped because opt file always takes
higher precedence over command line options. The test will just run
once using the options provided in the opt file.
For test runs specific to a given test suite, an alternative to
the use of <b>`--combination`</b> is to create a
<b>combinations</b> file in the suite directory. The file
should contain a section of options for each test run. See @ref
PAGE_PASSING_OPTIONS.
For test specific combinations, onc can use
<b><em>test_name</em>.combinations</b> file in the test
directory.
</li>
<li>
<tt>`--comment`=<b>str</b></tt>
Write <b><em>str</em></b> to the output within lines filled
with #, as a form of banner.
</li>
<li>
<tt>`--compress`</tt>
Compress all information sent between the client and the server
if both support compression.
</li>
<li>
<tt>`--cursor-protocol`</tt>
Pass the <b>`--cursor-protocol`</b> option to @ref
PAGE_MYSQLTEST "mysqltest" (implies <b>`--ps-protocol`</b>).
</li>
<li>
<tt>`--dbx`</tt>
Start <b>mysqld</b> in the <b>dbx</b> debugger.
</li>
<li>
<tt>`--ddd`</tt>
Start <b>mysqld</b> in the <b>ddd</b> debugger.
</li>
<li>
<tt>`--debug`</tt>
Dump trace output for all clients and servers.
</li>
<li>
<tt>`--debugger`=<b>debugger</b></tt>
Start <b>mysqld</b> using the named debugger.
</li>
<li>
<tt>`--debug-common`</tt>
This option works similar to <b>`--debug`</b> but turns on
debug only for the debug macro keywords <b>query</b>,
<b>info</b>, <b>error</b>, <b>enter</b>, <b>exit</b>
which are considered the most commonly used.
</li>
<li>
<tt>`--debug-server`</tt>
Runs <b>mysqld.debug</b> (if available) instead of
<b>mysqld</b> as server. If it does find <b>mysqld.debug</b>,
it will search for plugin libraries in a subdirectory
<b>debug</b> under the directory where it's normally located.
This option does not turn on trace output and is independent of
the <b>debug</b> option.
</li>
<li>
<tt>`--debug-sync-timeout`=<b>seconds</b></tt>
Controls whether the Debug Sync facility for testing and
debugging is enabled. The option value is a timeout in seconds.
The default value is 300. A value of 0 disables Debug Sync. The
value of this option also becomes the default timeout for
individual synchronization points.
@ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" passes
<b>`--loose-debug-sync-timeout`=<em>seconds</em></b> to
<b>mysqld</b>. The <b>`--loose`</b> prefix is used so that
<b>mysqld</b> does not fail if Debug Sync is not compiled in.
For information about using the Debug Sync facility for testing,
see @ref PAGE_THREAD_SYNCHRONIZATION.
</li>
<li>
<tt>`--default-myisam`</tt>
Use <b>MyISAM</b> as the default storage engine for all except
<b>InnoDB</b>-specific tests. This option is off by default.
</li>
<li>
<tt>`--defaults-file`=<b>file_name</b></tt>
Use the named file as fixed config file template for all tests.
</li>
<li>
<tt>`--defaults_extra_file`=<b>file_name</b></tt>
Add setting from the named file to all generated configs.
</li>
<li>
<tt>`--do-suite`=<b>prefix or regex</b></tt>
Run all test cases from suites having a name that begins with
the given <b><em>prefix</em></b> value or matches the regular
expression. If the argument matches no existing suite, @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" aborts.
The argument for the <b>`--do-suite`</b> option allows more
flexible specification of which tests to perform. See the
description of the <b>`--do-test`</b> option for details.
In case a suite or a list of suites is specified using the
<b>`--suite`</b> option along with a pattern or regular
expression given through <b>`--do-suite`</b>, only suite(s)
from the list which match the prefix or regular expression
are picked up.
When the <b>`--do-suite`</b> option is specified more than once
on the command line, only the last occurrence is considered.
</li>
<li>
<tt>`--do-test`=<b>prefix or regex</b></tt>
Run all test cases having a name that begins with the given
<b><em>prefix</em></b> value or matches the regular expression.
This option provides a convenient way to run a family of
similarly named tests.
The argument for the <b>`--do-test`</b> option allows more
flexible specification of which tests to perform. If the
argument contains a pattern metacharacter other than a lone
period, it is interpreted as a Perl regular expression and
applies to test names that match the pattern. If the argument
contains a lone period or does not contain any pattern
metacharacters, it is interpreted the same way as previously and
matches test names that begin with the argument value. For
example, <b>`--do-test`=testa</b> matches tests that begin with
<b>testa</b>, <b>`--do-test`=main.testa</b> matches tests in the
<b>main</b> test suite that begin with <b>testa</b>, and
<b>`--do-test`=main.*testa</b> matches test names that contain
<b>main</b> followed by <b>testa</b> with anything in between.
In the latter case, the pattern match is not anchored to the
beginning of the test name, so it also matches names such as
<b>xmainytestz</b>.
</li>
<li>
<tt>`--do-test-list`=<b>file</b></tt>
Run all tests listed in the file <b><em>file</em></b>. In this
file, tests should be listed one per line in any of the
following forms.
@verbatim
<test_name>
<test_name>.test
<suite_name>.<test_name>
<suite_name>.<test_name>.test
path_to_the_test_file
@endverbatim
Path to the test file should either be an absolute path or a
relative path from base directory.
To run a test present in a non-default test suite, either the
test name qualified with the suite name i.e
<b>suite_name.test_name[.test]</b> or a <b>path</b> to the
test file should be mentioned.
A line beginning with <b>#</b> will be ignored and is considered
as a comment. Similarly an empty line in the file is also
ignored.
For example, consider a test list file <b>test_list</b>
containing following tests.
@verbatim
# Main suite test '1st.test'
1st
1st.test
main.1st
main.1st.test
mysql-test/t/1st.test
# GIS suite test 'geohash_functions.test'
gis.geohash_functions
mysql-test/suite/gis/t/geohash_functions.test
# Non-default suite 'test_services'
test_services.test_services
mysql-test/suite/test_services/t/test_services.test
# Internal suite test 'i_main.user_var'
i_main.user_var
internal/mysql-test/suite/i_main/t/user_var.test
@endverbatim
Following command runs the list of tests mentioned in the file.
@verbatim
./mysql-test-run.pl --do-test-list=test_list
@endverbatim
If both <b>`--suite`</b> and <b>`--do-test-list`</b> are given,
and if suite name is <em>not</em> part of the test names listed
in the file, then those tests are searched only in the suites
mentioned in <b>`--suite`</b> option.
</li>
<li>
<tt>`--enable-disabled`</tt>
Ignore any <b>disabled.def</b> file, and run also tests marked
as disbaled. Success or failure of those tests will be reported
the same way as other tests.
@note
This option is enabled by default when test cases are specified
on command line.
</li>
<li>
<tt>`--explain-protocol`</tt>
Run <b>EXPLAIN EXTENDED</b> on all <b>SELECT</b>, <b>INSERT</b>,
<b>REPLACE</b>, <b>UPDATE</b> and <b>DELETE</b> queries.
</li>
<li>
<tt>`--extern` <b>option=value</b></tt>
Use an already running server. The option/value pair is what is
needed by the <b>mysql</b> client to connect to the server. Each
<b>`--extern`</b> can only take one option/value pair as
argument, so it you need more you need to repeat
<b>`--extern`</b> for each of them.
@verbatim
./mysql-test-run.pl --extern socket=var/tmp/mysqld.1.sock main.1st
@endverbatim
During server initialization, @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl" creates a default database <b>test</b> which
is used while establishing an initial connection with the
server. When running a test case with <b>--extern</b> option, if
<b>test</b> database doesn't exist on an already running server,
then the test case will fail with following error.
@verbatim
mysqltest: Could not open connection 'default': 1049 Unknown database 'test'
@endverbatim
So if you're running a test case on an already running server
using <b>--extern</b> option, it is necessary to create
<b>test</b> database on the server before running the test case
if it doesn't exist.
Similarly, @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl"
creates <b>mtr</b> database during server initialization which
contains tables and procedures used to suppress global or test
specific warnings. If a test case refers to this database and
the database doesn't exist on running server, then the test case
will fail.
@note
If a test case has an <b>.opt</b> file that requires the server
to be restarted with specific options, the file will not be
used. The test case likely will fail as a result.
</li>
<li>
<tt>`--fast`</tt>
Do not perform controlled shutdown when servers need to be
restarted or at the end of the test run. This is equivalent to
using <b>`--shutdown-timeout`=0</b>.
</li>
<li>
<tt>`--force`</tt>
Normally, @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" exits
if a test case fails. <b>`--force`</b> causes execution to
continue regardless of test case failure.
</li>
<li>
<tt>`--force-restart`</tt>
Always restart the server(s) between each tast case, whether
it's needed or not. Will also restart between repeated runs of
the same test case. This may be useful e.g. when looking for the
source of a memory leak, as there will only have been one test
run before the server exits.
Enabling this option will cause @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl" to restart the server(s) on a newly
intialized data directory.
This option can also be mentioned in
<b><em>test-name</em>-master.opt</b> file for a test case to
restart the server(s) before it runs.
</li>
<li>
<tt>`--gcov`</tt>
Run tests with the <b>gcov</b> test coverage tool.
</li>
<li>
<tt>`--gdb`</tt>
Start <b>mysqld</b> in the <b>gdb</b> debugger.
</li>
<li>
<tt>`--gprof`</tt>
Run tests with the <b>gprof</b> profiling tool.
</li>
<li>
<tt>`--include-ndbcluster`, `--include-ndb`</tt>
Run also tests that need Cluster.
</li>
<li>
<tt>`--initialize`=<b>value</b></tt>
Extra bootstrap options that need be to be passed during
the server initialization process can be passed as a value
to <b>`--initialize`</b>. The server is then started with
the specified value. Only one option may be specified in
<b>value</b>; to specify more than one, use additional
<b>`--initialize`</b> options.
Options passed as a value to <b>`--mysqld`</b> will have
precedence over the options passed to <b>`--initialize`</b>,
regardless of the order in which they passed on the command
line.
</li>
<li>
<tt>`--json-explain-protocol`</tt>
Run <b>EXPLAIN FORMAT=JSON</b> on all <b>SELECT</b>,
<b>INSERT</b>, <b>REPLACE</b>, <b>UPDATE</b> and <b>DELETE</b>
queries.
</li>
<li>
<tt>`--manual-boot-gdb`</tt>
This option is similar to <b>`--boot-gdb`</b> but attaches the
debugger to the server during the bootstrapping process,
permitting the use of a remote debugger.
</li>
<li>
<tt>`--manual-dbx`</tt>
Use a server that has already been started by the user in the
<b>dbx</b> debugger.
</li>
<li>
<tt>`--manual-ddd`</tt>
Use a server that has already been started by the user in the
<b>ddd</b> debugger.
</li>
<li>
<tt>`--manual-debug`</tt>
Use a server that has already been started by the user in a
debugger.
</li>
<li>
<tt>`--manual-gdb`</tt>
Use a server that has already been started by the user in the
<b>gdb</b> debugger.
</li>
<li>
<tt>`--mark-progress`</tt>
Marks progress with timing (in milliseconds) and line number in
<b>var/log/<em>testname</em>.progress</b>.
</li>
<li>
<tt>`--max-connections`=<b>num</b></tt>
The maximum number of simultaneous server connections that may
be used per test. If not set, the maximum is 128. Minimum
allowed limit is 8, maximum is 5120. Corresponds to the same
option for @ref PAGE_MYSQLTEST "mysqltest".
</li>
<li>
<tt>`--max-save-core`=<b>N</b></tt>
Limit the number of core files saved, to avoid filling up disks
in case of a frequently crashing server. Defaults to 5, set to 0
for no limit. May also be set with the environment variable
<tt>MTR_MAX_SAVE_CORE</tt>.
</li>
<li>
<tt>`--max-save-datadir`=<b>N</b></tt>
Limit the number of data directories saved after failed tests,
to avoid filling up disks in case of frequent failures. Defaults
to 20, set to 0 for no limit. May also be set with the
environment variable <b>MTR_MAX_SAVE_DATADIR</b>.
</li>
<li>
<tt>`--max-test-fail`=<b>N</b></tt>
Stop execution after the specified number of tests have failed,
to avoid using up resources (and time) in case of massive
failures. retries are noe counted. Defaults to 10, set to 0 for
no limit. May also be set with the environment variable
<b>MTR_MAX_TEST_FAIL</b>.
</li>
<li>
<tt>`--mem`</tt>
This option is not supported on Windows and on MacOS.
Run the test suite in memory, using tmpfs or ramdisk. This can
decrease test times significantly, in particular if you would
otherwise be running over a remote file system. @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" attempts to find a
suitable location using a built-in list of standard locations
for tmpfs and puts the <b>var</b> directory there. This option
also affects placement of temporary files, which are created in
<b>var/tmp</b>.
The default list includes <b>/dev/shm</b>, <b>/run/shm</b> and
<b>/tmp</b>. You can also enable this option by setting the
environment variable <b>MTR_MEM[=<em>dir_name</em>]</b>. If
<b><em>dir_name</em></b> is given, it is added to the beginning
of the list of locations to search, so it takes precedence over
any built-in locations.
Once you have run tests with <b>`--mem`</b> within a
<b>mysql-test</b> directory, a soflink <b>var</b> will have been
set up to the temporary directory, and this will be re-used the
next time, until the soflink is deleted. Thus, you do not have
to repeat the <b>`--mem`</b> option next time.
</li>
<li>
<tt>`--mysqld`=<b>value</b></tt>
Extra option to pass to <b>mysqld</b>. Only one option may be
specified in <b>value</b>; to specify more than one, use
additional <b>--mysqld</b> options. See @ref PAGE_PASSING_OPTIONS.
</li>
<li>
<tt>`--mysqld-env`=<b>variable</b>=<b>value</b></tt>
Sets (or changes) an environment variable before starting
<b>mysqld</b>. Varibles set in the environment from which you
run @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" will
normally also be propagated to <b>mysqld</b>, but there may be
cases where you want a setting just for a single run, or you may
not want the setting to affect other programs. You may use
additional <b>`--mysqld-env`</b> options to set more than one
variable.
</li>
<li>
<tt>`--mysqltest`=<b>options</b></tt>
Extra options to pass to @ref PAGE_MYSQLTEST "mysqltest".
</li>
<li>
<tt>`--ndb-connectstring`=<b>str</b></tt>
Pass <b>`--ndb-connectstring`=<em>str</em></b> to the master
MySQL server. This option also prevents @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" from starting a
cluster. It is assumed that there is already a cluster running
to which the server can connect with the given connectstring.
</li>
<li>
<tt>`--no-skip`</tt>
This option forces all tests to run, ignoring any
<b>`--skip`</b> commands used in the test. This ensures that all
tests are run. An excluded list (<b>excludenoskip.list</b>) is
maintained to track which tests should continue to be skipped.
The <b>`--no-skip`</b> option continues to skip the tests that
are named in the excluded list. The default value of
<b>--no-skip</b> introduced variable is OFF, which implies users
are not forced to run all tests unless the <b>--no-skip</b> is
explicitly used.
@verbatim
shell> mysql-test-run.pl --suite=innodb --no-skip
@endverbatim
</li>
<li>
<tt>`--nocheck-testcases`</tt>
Disable the check for test case side effects. For additional
information, see the description of the
<b>`--check-testcases`</b> option.
</li>
<li>
<tt>`--noreorder`</tt>
Do not reorder tests to reduce number of restarts, but run them
in exactly the order given. If a whole suite is to be run, the
tests are run in alphabetic order, though similiar combinations
will be grouped together. If more than one suite is listed, the
tests are run one suite at a time, in the order listed.
</li>
<li>
<tt>`--notimer`</tt>
Cause @ref PAGE_MYSQLTEST "mysqltest" not to generate a timing
file. The effect of this is that the report from each test case
does not include the timing in milliseconds as it normally does.
</li>
<li>
<tt>`--nounit-tests`</tt>
Do not run unit tests, overriding default behavior or setting of
the <b>MTR_UNIT_TESTS</b> variable.
</li>
<li>
<tt>`--nowarnings`</tt>
Do not look for and report errors and warning in the server logs.
@note
In addition to being passed as a command-line option,
<b>`--nowarnings`</b> can also be passed in the <b>.opt</b> file of
a test case.
</li>
<li>
<tt>`--only-big-tests`</tt>
This option causes only big tests to run. Normal (non-big) tests
are skipped. If both <b>`--big-test`</b> and
<b>`--only-big-tests`</b> are given, <b>`--only-big-tests`</b>
is ignored.
</li>
<li>
<tt>`--opt-trace-protocol`</tt>
Prints the @ref PAGE_OPT_TRACE "optimizer trace" of SQL statements in a test.
Running any MTR test with this option executes the following SQL
statement after every <b>DML statement</b> that it encounters:
@verbatim
SELECT trace FROM information_schema.optimizer_trace /* injected by --opt-trace-protocol */;
@endverbatim
</li>
<li>
<tt>`--parallel`={<b>N</b>|auto}</tt>
Run tests using <b><em>N</em></b> parallel threads. By default,
1 thread is used. Use <b>`--parallel`=auto</b> to set
<b><em>N</em></b> automatically.
Setting the <b>MTR_PARALLEL</b> environment variable to
<b><em>N</em></b> has the same effect as specifying
<b>`--parallel`=<em>N</em></b>.
The <b>MTR_MAX_PARALLEL</b> environment variable, if set,
specifies the maximum number of parallel workers that can be
spawned when the <b>`--parallel`=auto</b> option is specified.
If <b>`--parallel`=auto</b> is not specified,
<b>MTR_MAX_PARALLEL</b> variable has no effect.
</li>
<li>
<tt>`--port-base`=<b>P</b></tt>
Specify base of port numbers to be used; a block of 10 will be
allocated. <b><em>P</em></b> should be divisible by 10; if it is
not, it will be rounded down. If running with more than one
parallel test thread, thread 2 will use the next block of 10 and
so on.
If the port number is given as <b>auto</b>, which is also the
default, @ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" will
allocate a number unique to this host. The value may also be
given with the environment variable <b>MTR_PORT_BASE</b>.
<b>`--port-base`</b> was added as a more logical alternative to
<b>`--build-thread`</b>. If both are used, <b>`--port-base`</b>
takes precedence.
</li>
<li>
<tt>`--print-testcases`</tt>
Do not run any tests, but print details about all tests, in the
order they would have been run.
</li>
<li>
<tt>`--ps-protocol`</tt>
Pass the <b>`--ps-protocol`</b> option to @ref PAGE_MYSQLTEST
"mysqltest".
</li>
<li>
<tt>`--quiet`</tt>
Reuse the output buffer and maintain a single line for reporting
successful tests, skipped tests and disabled tests. Failed tests
and the necessary information about the failure will be printed
on a separate line.
When <b>`--quiet`</b> option is enabled, MTR prints only the
test name and result of the test run.
</li>
<li>
<tt>`--record`</tt>
Pass the <b>`--record`</b> option to @ref PAGE_MYSQLTEST
"mysqltest". This option requires a specific test case to be
named on the command line.
</li>
<li>
<tt>`--reorder`</tt>
Reorder tests to minimize the number of server restarts needed.
This is the default behavior. There is no guarantee that a
particular set of tests will always end up in the same order.
</li>
<li>
<tt>`--repeat`=<b>N</b></tt>
Run each test <b><em>N</em></b> number of times, in parallel if
<b>`--parallel`</b> option value is greater than 1.
</li>
<li>
<tt>`--report-features`</tt>
Display the output of <b>SHOW ENGINES</b> and <b>SHOW
VARIABLES</b>. This can be used to verify that binaries are
built with all required features.
</li>
<li>
<tt>`--report-times`</tt>
At the end of the test run, write a summary of how much time was
spent in various phases of execution. If you run with
<b>`--parallel`</b>, the total will exceed the wall clock time
passed, since it will be summed over all threads.
The times reported should only be treated as approximations, and
the exact points where the time is taken may also change between
releases. If the test run is aborted, including if a test fails
and <b>`--force`</b> is not in use, the time report will not
be produced.
</li>
<li>
<tt>`--report-unstable-tests`</tt>
The option can be used to distinguish unstable tests which pass
on at least one retry attempt from hard failing ones. Unstable
tests are reported separately in the end summary in the format:
<b>test_name(num_of_failures/num_of_attempts)</b>.
In case all failures encountered are due to unstable tests, MTR
will print the below warning and exit with a zero status code.
@verbatim
mysql-test-run: WARNING: There are failures due to unstable test cases.
However, the tests are not hard-failing.
@endverbatim
This option has no effect unless <b>`--force`</b> is used and
both <b>`--retry`</b> and <b>`--retry-failure`</b> are set to
values greater than 1.
</li>
<li>
<tt>`--retry`=<b>N</b></tt>
If a test fails, it is retried up to a maximum of
<b><em>N</em></b> runs, but will terminate after 2 failures.
Default is 3, set to 1 or 0 for no retries. This option has no
effect unless <b>`--force`</b> is also used; without it, test
execution will terminate after the first failure.
The <b>`--retry`</b> and <b>`--retry-failure`</b> options do not
affect how many times a test repeated with <b>`--repeat`</b> may
fail in total, as each repetition is considered a new test case,
which may in turn be retried if it fails.
</li>
<li>
<tt>`--retry-failure`=<b>N</b></tt>
Allow a failed and retried test to fail more than the default 2
times before giving it up. Setting it to 0 or 1 effectively
turns off retries
</li>
<li>
<tt>`--non-parallel-test`</tt>
Allow tests marked as "non-parallel" to run. Tests can be thus
marked by including the line
<b>`--source` include/not_parallel.inc</b>, and they will only
be run if this option is enabled.
</li>
<li>
<tt>`--sanitize`</tt>
Scan the server log files for warnings from various sanitizers.
Use of this option assumes that MySQL was configured with
[-DWITH_ASAN]
(https://dev.mysql.com/doc/refman/8.0/en/source-configuration-options.html#option_cmake_with_asan)
or [-DWITH_UBSAN]
(https://dev.mysql.com/doc/refman/8.0/en/source-configuration-options.html#option_cmake_with_ubsan).
The <b>TSAN_OPTIONS</b> environment variable can be set to
specify the path name of a file containing ThreadSanitizer
suppressions.
</li>
<li>
<tt>`--shutdown-timeout`=<b>seconds</b></tt>
Max number of seconds to wait for servers to do controlled
shutdown before killing them. Default is 10.
</li>
<li>
<tt>`--skip-combinations`</tt>
Do not apply combinations; ignore combinations file or option.
</li>
<li>
<tt>`--skip-ndbcluster`, `--skip-ndb`</tt>
Do not start NDB Cluster; skip Cluster test cases. This option
only has effect if you do have NDB, if not it will have no
effect as it cannot run those tests anyway.
</li>
<li>
<tt>`--skip-ndbcluster-slave`, `--skip-ndb-slave`</tt>
Do not start an NDB Cluster slave.
</li>
<li>
<tt>`--skip-rpl`</tt>
Skip replication test cases.
</li>
<li>
<tt>`--skip-test`=<b>regex</b></tt>
Specify a regular expression to be applied to test case names.
Cases with names that match the expression are skipped. tests to
skip.
The argument for the <b>`--skip-test`</b> option allows more
flexible specification of which tests to skip. If the argument
contains a pattern metacharacter other than a lone period, it is
interpreted as a Perl regular expression and applies to test
names that match the pattern. See the description of the
<b>`--do-test`</b> option for details.
</li>
<li>
<tt>`--skip-test-list`=<b>file</b></tt>
Specify a file listing tests that should be skipped (disabled).
The file has the same format as the <b>disabled.def</b> file
listing disabled tests. With this option, disabling can be done
on a case by case basis.
</li>
<li>
<tt>`--skip-*`</tt>
<b>`--skip-*`</b> options not otherwise recognized by @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" are passed to the
master server.
</li>
<li>
<tt>`--sleep`=<b>N</b></tt>
Pass <b>`--sleep`=<em>N</em></b> to @ref PAGE_MYSQLTEST
"mysqltest".
</li>
<li>
<tt>`--sp-protocol`</tt>
Pass the <b>`--sp-protocol`</b> option to @ref PAGE_MYSQLTEST
"mysqltest".
</li>
<li>
<tt>`--start`</tt>
Initialize and start servers with the startup settings for the
specified test case. You can use this option to start a server
to which you can connect later. For example, after building a
source distribution you can start a server and connect to it
with the <b>mysql</b> client like this:
@verbatim
shell> cd mysql-test
shell> ./mysql-test-run.pl --start alias &
shell> ../mysql -S ./var/tmp/master.sock -h localhost -u root
@endverbatim
If no tests are named on the command line, the server(s) will be
started with settings for the first test that would have been
run without the <b>`--start`</b> option.
@ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" will stop once
the server has been started, but will terminate if the server
dies. If killed, it will also shut down the server.
</li>
<li>
<tt>`--start-and-exit`</tt>
This is similar to <b>`--start`</b>, but @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" terminates once the
server has been started, leaving just the server process
running.
</li>
<li>
<tt>`--start-dirty`</tt>
This is similar to <b>`--start`</b>, but will skip the
database initialization phase and assume that database files are
already available. Usually this means you must have run another
test first.
</li>
<li>
<tt>`--start-from`=<b>test_name</b></tt>
@ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" sorts the list
of names of the test cases to be run, and then begins with
<b><em>test_name</em></b>.
</li>
<li>
<tt>`--strace-client`</tt>
Create <b>strace</b> output for @ref PAGE_MYSQLTEST "mysqltest".
Will produce default <b>strace</b> output as
<b>mysqltest.strace</b>. Note that this will be overwritten
for each new test case, so it's most useful for running only one
test.
The <b>strace-client</b> option is only supported on Linux.
</li>
<li>
<tt>`--strace-server`</tt>
Create <b>strace</b> output for the server. Will produce default
<b>strace</b> output as <b>mysqld.1.strace</b>. Note that this
will be overwritten each time the server is restarted, so it's
most useful for running a single test, or if you want trace from
the first test that fails.
The <b>strace-server</b> option is available on Linux only.
</li>
<li>
<tt>`--stress`=<b>stress options</b></tt>
Start a server, but instead of running a test, run @ref
PAGE_MYSQLTEST "mysql-stress-test.pl" with the supplied
arguments. Arguments needed to communicate with the server will
be automatically provided, the rest should be given as arguments
to this option. Command line options for @ref PAGE_MYSQLTEST
"mysql-stress-test.pl" should be separeted by a comma.
</li>
<li>
<tt>`--suite(s)`=<b>{suite_name|suite_list|suite_set}</b></tt>
Run a suite or a comma separated list of suites or those suites
which fall under the specified suite set. If the option is not
specified explicitly, MTR assumes that it needs to use the
default suite set for the test run.
The suite set's MTR can use are case insensitive and take the
below values:
@verbatim
default - To run the default list of suites.
all - To scan the mysql directory and run all available suites.
non-default - To scan the mysql directory for available suites and
collect only the non-default suites.
@endverbatim
The suite set 'all' is used implicitly if neither a suite nor a
suite list is specified and\n
(i) There are tests given on the MTR command line <b>or</b>\n
(ii) Any of the following options are used: <b>--do-suite</b>,
<b>--do-test</b>, <b>--do-test-list</b>.
Note that suite sets 'all' and 'non-default' do not include ndb test
suites in case ndb cluster is not enabled.
If a suite set is specified in the suite list, MTR does not treat it
as a suite set and considers it as the name of a suite to be run.
</li>
<li>
<tt>`--suite-timeout`=<b>minutes</b></tt>
Specify the maximum test suite runtime in minutes.
</li>
<li>
<tt>`--summary-report`=<b>file_name</b></tt>
Generate a plain text version of the test summary only and write
it to the file named as the option argument. The file is
suitable for sending by email.
</li>
<li>
<tt>`--test-progress`[={0|1}]</tt>
Print the percentage of tests completed. This option is enabled
by default. The argument to <b>`--test-progress`</b> is
optional. To disable it, set the value to <b>0</b>.
For example, consider a test suite <b>sample_test_suite</b>
containing 3 tests.
@verbatim
./mysql-test-run.pl --suite=sample_test_suite [--test-progress]
@endverbatim
Running the suite with <b>`--test-progress`</b> option enabled
will print the percentage of tests completed.
@verbatim
[ 33%] sample_test_suite.1st [ pass ] 1
[ 66%] sample_test_suite.2nd [ pass ] 1
[100%] sample_test_suite.3rd [ pass ] 1
@endverbatim
</li>
<li>
<tt>`--testcase-timeout`=<b>minutes</b></tt>
Specify the maximum test case runtime in minutes.
@note
When a test case is run with <b>valgrind</b> option enabled, the
test case timeout value becomes 10 times the specified value.
For example, running a test case with timeout value
<b>1 minute</b> and <b>valgrind</b> enabled will increase the
timeout value to <b>10 minutes</b>.
</li>
<li>
<tt>`--timediff`</tt>
Adds to each test report for a test case, the total time in
seconds and milliseconds passed since the preceding test ended.
This option can only be used together with
<b>`--timestamp`</b>, and has no effect without it.
</li>
<li>
<tt>`--timer`</tt>
Cause @ref PAGE_MYSQLTEST "mysqltest" to generate a timing file.
The default file is named <b>./var/log/timer</b>.
</li>
<li>
<tt>`--timestamp`</tt>
Prints a timestamp before the test case name in each test report
line, showing when the test ended.
</li>
<li>
<tt>`--tmpdir`=<b>path</b></tt>
The directory where temporary file are stored. The default
location is <b>./var/tmp</b>. The environment variable
<b>MYSQL_TMP_DIR</b> will be set to the path for this directory,
whether it has the default value or has been set explicitly.
This may be referred to in tests.
</li>
<li>
<tt>`--unit-tests`</tt>
Force running of unit tests, overriding default behavior or
setting of the <b>MTR_UNIT_TESTS</b> variable.
</li>
<li>
<tt>`--unit-tests-report`</tt>
Extend the unit test run by also outputting the log from the
test run, independently of whether it succeeded or not. This
option implies <b>`--unit-tests`</b> so it is not necessary to
specify both.
</li>
<li>
<tt>`--user`=<b>user_name</b></tt>
The MySQL user name to use when connecting to the server.
</li>
<li>
<tt>`--user-args`</tt>
Drops all non-essential command line arguments to the
<b>mysqld</b> server, except those supplied with
<b>`--mysqld`</b> arguemnts, if any. Only works in combination
with <b>`--start`</b>, <b>`--start-and-exit`</b> or
<b>`--start-dirty`</b>, and only if no test name is given.
</li>
<li>
<tt>`--valgrind`</tt>
Run @ref PAGE_MYSQLTEST "mysqltest" and <b>mysqld</b> with
<b>valgrind</b>. This and the following <b>`--valgrind`</b>
options require that the executables have been build with
<b>valgrind</b> support.
When the server is run with valgrind, an extra pass over the
server log file(s) will be performed after all tests are run,
and any report with problems that have been reported at server
shutdown will be extracted and printed. The most common warnings
are memory leaks. With each report will also be listed all tests
that were run since previous server restart; one of these is
likely to have caused the problem.
A final "pseudo" test named <b>valgrind_report</b> is added to
the list of tests when the server is run in valgrind. This test
is reported as failed if any such shutdown warnings were
produced by valgrind. Pass or failure of this test is also added
to the total test count reported.
@note
When a test case is run with <b>valgrind</b> option enabled, the
test case timeout value becomes 10 times the specified value.
For example, running a test case with timeout value
<b>1 minute</b> and <b>valgrind</b> enabled will increase the
timeout value to <b>10 minutes</b>.
</li>
<li>
<tt>`--valgrind-clients`</tt>
Run all clients started by <b>.test</b> files with
<b>valgrind</b>. This option requires <b>valgrind 3.9</b> or
later.
</li>
<li>
<tt>`--valgrind-mysqld`</tt>
Run the <b>mysqld</b> server with <b>valgrind</b>.
</li>
<li>
<tt>`--valgrind-mysqltest`</tt>
Run @ref PAGE_MYSQLTEST "mysqltest" with <b>valgrind</b>.
</li>
<li>
<tt>`--valgrind-option`=<b>str</b></tt>
Extra options to pass to <b>valgrind</b>.
</li>
<li>
<tt>`--valgrind-path`=<b>path</b></tt>
Specify the path name to the valgrind executable.
</li>
<li>
<tt>`--vardir`=<b>path</b></tt>
Specify the path where files generated during the test run are
stored. The default location is <b>./var</b>. The environment
variable <b>MYSQLTEST_VARDIR</b> will be set to the path for
this directory, whether it has the default value or has been set
explicitly. This may be referred to in tests.
</li>
<li>
<tt>`--verbose`</tt>
Give more verbose output regarding test execution. Note that the
output generated within each test case is not affected.
</li>
<li>
<tt>`--verbose-restart`</tt>
Write when and why servers are restarted between test cases.
</li>
<li>
<tt>`--view-protocol`</tt>
Pass the <b>`--view-protocol`</b> option to @ref
PAGE_MYSQLTEST "mysqltest".
</li>
<li>
<tt>`--vs-config`=<b>config_val</b></tt>
Specify the configuration used to build MySQL (for example,
<b>--vs-config=debug --vs-config=release</b>). This option
is for Windows only.
</li>
<li>
<tt>`--wait-all`</tt>
If <b>`--start`</b> or <b>`--start-dirty`</b> is used, wait
for all servers to exit before termination. Otherise, it will
terminate if one (of several) servers is restarted.
</li>
<li>
<tt>`--warnings`</tt>
Search the server log for errors or warning after each test and
report any suspicious ones; if any are found, the test will be
marked as failed. This is the default behavior, it may be turned
off with <b>`--nowarnings`</b>.
</li>
<li>
<tt>`--with-ndbcluster-only`</tt>
Run only test cases that have <b>ndb</b> in their name.
</li>
<li>
<tt>`--xml-report`=<b>file_name</b></tt>
Generate an xml file containing result of the test run and write
it to the file named as the option argument. It includes
suite-wise and overall statistics like the number of tests run,
number of failures, number of disabled and skipped tests along
with information about each individual test according to its
outcome.
The xml report's structure can be found below :
@verbatim
<testsuites ... >
<testsuite ... >
<testcase ... />
<testcase ... >
<failure ... > ... </failure>
</testcase>
</testsuite>
</testsuites>
@endverbatim
</li>
</ul>
@note
The hostname resolves to 127.0.0.1 and not to the actual IP address.
*/
###############################################################################
## mysql-stress-test.pl — Server Stress Test Program
/**
@page PAGE_MYSQL_STRESS_TEST_PL mysql-stress-test.pl — Server Stress Test Program
The @ref PAGE_MYSQL_STRESS_TEST_PL "mysql-stress-test.pl" Perl
script performs stress-testing of the MySQL server.
@ref PAGE_MYSQL_STRESS_TEST_PL "mysql-stress-test.pl" requires
version of Perl that has been built with threads support.
Invoke @ref PAGE_MYSQL_STRESS_TEST_PL "mysql-stress-test.pl" like
this:
@verbatim
shell> mysql-stress-test.pl [options]
@endverbatim
@ref PAGE_MYSQL_STRESS_TEST_PL "mysql-stress-test.pl" supports the
following options:
<ul>
<li>
<tt>`--help`</tt>
Display a help message and exit.
</li>
<li>
<tt>`--abort-on-erro`r=<b>N</b></tt>
Causes the program to abort if an error with severity less than
or equal to N was encountered. Set to 1 to abort on any error.
</li>
<li>
<tt>`--check-tests-file`</tt>
Periodically check the file that lists the tests to be run. If
it has been modified, reread the file. This can be useful if you
update the list of tests to be run during a stress test.
</li>
<li>
<tt>`--cleanup`</tt>
Force cleanup of the working directory.
</li>
<li>
<tt>`--log-error-details`</tt>
Log error details in the global error log file.
</li>
<li>
<tt>`--loop-count`=<b>N</b></tt>
In sequential test mode, the number of loops to execute before
exiting.
</li>
<li>
<tt>`--mysqltest`=<b>path</b></tt>
The path name to the @ref PAGE_MYSQLTEST "mysqltest" program.
</li>
<li>
<tt>`--server-database`=<b>db_name</b></tt>
The database to use for the tests. The default is <b>test</b>.
</li>
<li>
<tt>`--server-host`=<b>host_name</b></tt>
The host name of the local host to use for making a TCP/IP
connection to the local server. By default, the connection is
made to <b>localhost</b> using a Unix socket file.
</li>
<li>
<tt>`--server-logs-dir`=<b>path</b></tt>
This option is required. path is the directory where all client
session logs will be stored. Usually this is the shared
directory that is associated with the server used for testing.
</li>
<li>
<tt>`--server-password`=<b>password</b></tt>
The password to use when connecting to the server.
</li>
<li>
<tt>`--server-port`=<b>port_num</b></tt>
The TCP/IP port number to use for connecting to the server.
The default is <b>3306</b>.
</li>
<li>
<tt>`--server-socket`=<b>file_name</b></tt>
For connections to <b>localhost</b>, the Unix socket file to
use, or, on Windows, the name of the named pipe to use. The
default if <b>/tmp/mysql.sock</b>.
</li>
<li>
<tt>`--server-user`=<b>user_name</b></tt>
The MySQL user name to use when connecting to the server. The
default is <b>root</b>.
</li>
<li>
<tt>`--sleep-time`=<b>N</b></tt>
The delay in seconds between test executions.
</li>
<li>
<tt>`--stress-basedir`=<b>path</b></tt>
This option is required. <b>path</b> is the working
directory for the test run. It is used as the temporary location
for result tracking during testing.
</li>
<li>
<tt>`--stress-datadir`=<b>path</b></tt>
The directory of data files to be used during testing. The
default location is the <b>data</b> directory under the
location given by the <b>`--stress-suite-basedir`</b> option.
</li>
<li>
<tt>`--stress-init-file`[=<b>path</b>]</tt>
<b>file_name</b> is the location of the file that
contains the list of tests to be run once to initialize the
database for the testing. If missing, the default file is
<b>stress_init.txt</b> in the test suite directory.
</li>
<li>
<tt>`--stress-mode`=<b>mode</b></tt>
This option indicates the test order in stress-test mode. The
<b>mode</b> value is either <b>random</b> to select tests in
random order or <b>seq</b> to run tests in each thread in the
order specified in the test list file. The default mode is
<b>random</b>.
</li>
<li>
<tt>`--stress-suite-basedir`=<b>path</b></tt>
This option is required. <b>path</b> is the directory
that has the <b>t</b> and <b>r</b> subdirectories containing
the test case and result files. This directory is also the
default location of the <b>stress-test.txt</b> file that
contains the list of tests. (A different location can be
specified with the <b>`--stress-tests-file`</b> option).
</li>
<li>
<tt>`--stress-tests-file`[=<b>file_name</b>]</tt>
Use this option to run the stress tests. <b>file_name</b>
is the location of the file that contains the list of tests. If
<b>file_name</b> is omitted, the default file is
<b>stress-test.txt</b> in the stress suite directory. (See
<b>`--stress-suite-basedir`</b>).
</li>
<li>
<tt>`--suite`=<b>suite_name</b></tt>
Run the named test suite. The default name is <b>main</b> (the
regular test suite located in the mysql-test directory).
</li>
<li>
<tt>`--test-count`=<b>N</b></tt>
The number of tests to execute before exiting.
</li>
<li>
<tt>`--test-duration`=<b>N</b></tt>
The duration of stress testing in seconds.
</li>
<li>
<tt>`--threads`=<b>N</b></tt>
The number of threads. The default is 1.
</li>
<li>
<tt>`--verbose`</tt>
Verbose mode. Print more information about what the program does.
</li>
</ul>
*/
###############################################################################
## mysqltest Language Reference
/**
@page PAGE_MYSQLTEST_LANGUAGE_REFERENCE mysqltest Language Reference
<h3>Table of Contents</h3>
- @subpage PAGE_MYSQL_TEST_INPUT_CONVENTIONS
- @subpage PAGE_MYSQL_TEST_COMMANDS
- @subpage PAGE_MYSQL_TEST_VARIABLES
- @subpage PAGE_MYSQL_TEST_FLOW_CONTROL
- @subpage PAGE_ERROR_HANDLING
This chapter describes the test language implemented by @ref
PAGE_MYSQLTEST "mysqltest". The language allows input to contain a
mix of comments, commands executed by @ref PAGE_MYSQLTEST
"mysqltest" itself, and SQL statements that @ref PAGE_MYSQLTEST
"mysqltest" sends to a MySQL server for execution.
Terminology notes:
------------------
<ul>
<li>
A “command” is an input test that @ref PAGE_MYSQLTEST
"mysqltest" recognizes and executes itself. A “statement” is
an SQL statement or query that @ref PAGE_MYSQLTEST "mysqltest"
sends to the MySQL server to be executed.
</li>
<li>
When @ref PAGE_MYSQLTEST "mysqltest" starts, it opens a
connection it calls <b>default</b> to the MySQL server, using
any connection parameters specified by the command options. (For
a local server, the default user name is <b>root</b>. For an
external server, the default user name is <b>test</b> or the
user specified with the <b>`--user`</b> option.) You can use
the <b>connect</b> command to open other connections, the
<b>connection</b> command to switch between connections, and
the <b>disconnect</b> command to close connections. However,
the capability for switching connections means that the
connection named <b>default</b> need not be the connection in
use at a given time. To avoid ambiguity, this document avoids
the term “default connection”. It uses the term “current
connection” to mean “the connection currently in use”, which
might be different from “the connection named <b>default</b>”.
</li>
</ul>
*/
###############################################################################
## mysqltest Input Conventions
/**
@page PAGE_MYSQL_TEST_INPUT_CONVENTIONS mysqltest Input Conventions
@ref PAGE_MYSQLTEST "mysqltest" reads input lines and processes
them as follows:
<ul>
<li>
“End of line” means a newline (linefeed) character. A carriage
return/linefeed (CRLF) pair also is allowable as as a line
terminator (the carriage return is ignored). Carriage return by
itself is not allowed as a line terminator.
</li>
<li>
A line that begins with "#" as the first nonwhitespace content
is treated as a comment that extends to the end of the line and
is ignored. Example:
@verbatim
# this is a comment
@endverbatim
</li>
<li>
Earlier versions would also allow comments beginning with “`--`”
unless the first word was a valid @ref PAGE_MYSQLTEST
"mysqltest" command, but this has been deprecated and is longer
allowed.
</li>
<li>
Other input is taken as normal command input. The command
extends to the next occurrence of the command delimiter, which
is semicolon (“<b>;</b>”) by default. The delimiter can be
changed with the <b>delimiter</b> command.
If @ref PAGE_MYSQLTEST "mysqltest" recognizes the first word of
the delimiter-terminated command, @ref PAGE_MYSQLTEST
"mysqltest" executes the command itself. Otherwise, @ref
PAGE_MYSQLTEST "mysqltest" assumes that the command is an SQL
statement and sends it to the MySQL server to be executed.
Because the command extends to the delimiter, a given input line
can contain multiple commands, and a given command can span
multiple lines. The ability to write multiple-line statements is
useful for making long statements more readable, such as a
<b>create table</b> statement for a table that has many
columns.
</li>
</ul>
After @ref PAGE_MYSQLTEST "mysqltest" reads a command up to a
delimiter and executes it, input reading restarts following the
delimiter and any remaining input on the line that contains the
delimiter is treated as though it begins on a new line. Consider the
following two input lines:
@verbatim
echo issue a select statement; select 1; echo done
issuing the select statement;
@endverbatim
That input contains two commands and one SQL statement:
@verbatim
echo issue a SELECT statement
SELECT 1;
echo done issuing the SELECT statement
@endverbatim
Similarly, "#" comments can begin on a command line following
a delimiter:
@verbatim
SELECT 'hello'; # select a string value
@endverbatim
On a multiple-line command, "#" or “`--`” at the beginning of the
second or following lines is not special. Thus, the second and third
lines of the following variable-assignment command are not taken as
comments. Instead, the variable <b>$a</b> is set to a value that
contains two linefeed characters:
@verbatim
let $a= This is a variable
# assignment that sets a variable
-- to a multiple-line value;
@endverbatim
`--` commands and normal commands have complementary properties with
regard to how @ref PAGE_MYSQLTEST "mysqltest" reads them:
- A “`--`” command is terminated by a newline, regardless of how
many delimiters it contains.
- A normal command (without “`--`”) is terminated by the delimiter
(semicolon), no matter how many newlines it contains.
@ref PAGE_MYSQLTEST "mysqltest" commands can be written either with
a leading “`--`”) or as normal command input (no leading “`--`”).
Use the command delimiter only in the latter case. Thus, these two
lines are equivalent:
@verbatim
--sleep 2
sleep 2;
@endverbatim
The equivalence is true even for the <b>delimiter</b> command. For
example, to set the delimiter to “<b>//</b>”, either of these
commands work:
@verbatim
--delimiter //
delimiter //;
@endverbatim
To set the delimiter back to “;”, use either of these commands:
@verbatim
--delimiter ;
delimiter ;//
@endverbatim
A potential ambiguity occurs because a command line can contain
either a @ref PAGE_MYSQLTEST "mysqltest" command or an SQL
statement. This has a couple of implications:
- No @ref PAGE_MYSQLTEST "mysqltest" command should be the same
as any keyword that can begin an SQL statement.
- Should extensions to SQL be implemented in the future, it is
possible that a new SQL keyword could be impossible for @ref
PAGE_MYSQLTEST "mysqltest" to recognize as such if that keyword
is already used as a @ref PAGE_MYSQLTEST "mysqltest" command.
Any ambiguity can be resolved by using the “`--`” syntax to force
interpetation as a @ref PAGE_MYSQLTEST "mysqltest" command, or the
<b>query</b> command to force interpretation as SQL.
All file paths used in test commands should use forward slash
\"<b>/</b>\" as the directory separator as in Unix. They will be
automatically converted when needed if the test is run on Windows.
We also recommend putting all temporary or auxiliary files made
during the test under the directory referred to by
<b>$MYSQL_TMP_DIR</b>. Do not put them under fixed full paths like
<b>/tmp</b>. This will help ensuring portability of the test, and
avoiding conflicts with other programs.
<b>$MYSQL_TMP_DIR</b> is equivalent to
<b>$MYSQLTEST_VARDIR/tmp</b> if you are not running with parallel
test threads, but if you run @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl" with <b>`--parallel`</b>, they will be different.
It is therefore best to be consistent and use <b>$MYSQL_TMP_DIR</b>.
Commands named <b>disable_X</b> or <b>enable_X</b>, except
<b>parsing</b>, <b>reconnect</b> and <b>rpl_parse</b>, can take an
optional modifier <b>ONCE</b>. If this is added, the relevant
setting is enabled or disabled only for the next command or
statement, after which it is reverted to whatever it was before.
Note that the word <b>ONCE</b> must be in upper case; this was
chosen in order to make it more visible when reading the test
script.
For example, <b>`--disable_query_log`</b> <b>ONCE</b> will
ensure query log is disabled for the next statement, but will not
affect whether or not query log is enabled for statements following
the next. It is possible to enable/disable more that one property
(e.g. both query log and result log) for a single statement using
the <b>ONCE</b> modifier.
*/
###############################################################################
## mysqltest Commands
/**
@page PAGE_MYSQL_TEST_COMMANDS mysqltest Commands
@ref PAGE_MYSQLTEST "mysqltest" supports the commands described in
this section. Command names are not case sensitive.
Some examples of command use are given, but you can find many more
by searching the test case files in the <b>mysql-test/t</b>
directory.
<ul>
<li>
<tt>append_file <b>file_name</b> [<b>terminator</b>]</tt>
<b>append_file</b> is like <b>write_file</b> except that the
lines up to the terminator are added to the end of the file.
The file is created if it does not exist. The file name argument
is subject to variable substitution.
@verbatim
write_file $MYSQL_TMP_DIR/data01;
line one for the file
line two for the file
EOF
append_file $MYSQL_TMP_DIR/data01;
line three for the file
EOF
@endverbatim
@verbatim
write_file $MYSQL_TMP_DIR/data02 END_OF_FILE;
line one for the file
line two for the file
END_OF_FILE
append_file $MYSQL_TMP_DIR/data02 END_OF_FILE;
line three for the file
END_OF_FILE
@endverbatim
</li>
<li>
<tt>cat_file <b>file_name</b></tt>
<b>cat_file</b> writes the contents of the file to the output.
The file name argument is subject to variable substitution.
@verbatim
cat_file $MYSQL_TMP_DIR/data01;
@endverbatim
</li>
<li>
<tt>change_user [<b>user_name</b>], [<b>password</b>],
[<b>db_name</b>]</tt>
Changes the current user and causes the database specified by
<b><em>db_name</em></b> to become the default database for the
current connection.
@verbatim
change_user root;
--change_user root,,test
@endverbatim
</li>
<li>
<tt>character_set <b>charset_name</b></tt>
Set the default character set to <b><em>charset_name</em></b>.
Initially, the character set is latin1.
@verbatim
character_set utf8;
--character_set sjis
@endverbatim
</li>
<li>
<tt>chmod <b>octal_mode file_name</b></tt>
Change the mode of the given file. The file mode must be given as
a four-digit octal number. The file name argument is subject to
variable substitution, but must evaluate to a literal file name,
not a file name pattern.
@verbatim
chmod 0644 $MYSQL_TMP_DIR/data_xxx01;
@endverbatim
</li>
<li>
<tt>connect (<b>name</b>, <b>host_name</b>,
<b>user_name</b>, <b>password</b>, <b>db_name</b>
[,<b>port_num</b> [,<b>socket</b> [,<b>options</b>
[,<b>default_auth</b> [,<b>compression algorithm</b>,
[,<b>compression level</b>]]]]]])</tt>
Open a connection to the server and make the connection the
current connection.
The arguments to <b>connect</b> are:
<ul>
<li>
<b><em>name</em></b> is the name for the connection (for use
with the <b>connection</b>, <b>disconnect</b>, and
<b>dirty_close</b> commands). This name must not already be
in use by an open connection.
</li>
<li>
<b><em>host_name</em></b> indicates the host where the
server is running.
</li>
<li>
<b><em>user_name</em></b> and <b><em>password</em></b> are
the user name and password of the MySQL account to use.
</li>
<li>
<b><em>db_name</em></b> is the default database to use. As a
special case, *<b>NO-ONE</b>* means that no default database
should be selected. You can also leave
<b><em>db_name</em></b> blank to select no database.
</li>
<li>
<b><em>port_num</em></b>, if given, is the TCP/IP port
number to use for the connection. This parameter can be
given by using a variable.
</li>
<li>
<b><em>socket</em></b>, if given, is the socket file to use
for connections to <b>localhost</b>. This parameter can be
given by using a variable.
</li>
<li>
<b><em>options</em></b> can be one or more of the following
words, separated by spaces:
<ul>
<li>
<tt>CLEARTEXT</tt>: Enable use of the cleartext authentication
plugin.
</li>
<li>
<tt>COMPRESS</tt>: Use the compressed client/server protocol,
if available.
</li>
<li>
<tt>PIPE</tt>: Use the named-pipe connection protocol, if
available.
</li>
<li>
<tt>SHM</tt>: Use the shared-memory connection protocol, if
available.
</li>
<li>
<tt>SOCKET</tt>: Use the socket-file connection protocol.
</li>
<li>
<tt>TCP</tt>: Use the TCP/IP connection protocol.
</li>
</ul>
Passing <b>PIPE</b> or <b>SHM</b> on non-Windows systems
causes an error, and, similarly, passing <b>SOCKET</b> on
Windows systems causes an error.
</li>
<li>
<b><em>default_auth</em></b> is the name of an
authentication plugin. It is passed to the
<b>mysql_options()</b> C API function using the
<b>MYSQL_DEFAULT_AUTH</b> option. If @ref PAGE_MYSQLTEST
"mysqltest" does not find the plugin, use the
<b>--plugin-dir</b> option to specify the directory where
the plugin is located.
</li>
<li>
<b><em>compression algorithm</em></b> is the name of compression
algorithm to be used to compress data transferred between client
server. It is passed to the <b>mysql_options()</b> C API function
using the <b>MYSQL_OPT_COMPRESSION_ALGORITHMS</b> option.
</li>
<li>
<b><em>zstd compression level</em></b> is the extent of compression
to be applied when zstd compression algorithm is used. It is passed to
the <b>mysql_options()</b> C API function using the
<b>MYSQL_OPT_COMPRESSION_ALGORITHMS</b> option.
</li>
<li>
<b><em>compression algorithm</em></b> is the name of compression
algorithm to be used to comrpess data transferred between client
server. It is passed to the <b>mysql_options()</b> C API function
using the <b>MYSQL_OPT_COMPRESSION_ALGORITHMS</b> option.
</li>
<li>
<b><em>compression level</em></b> is the extent of compression to
be applied based on the compression algorithm used. It is passed to
the <b>mysql_options()</b> C API function using the
<b>MYSQL_OPT_COMPRESSION_ALGORITHMS</b> option.
</li>
</ul>
To omit an argument, just leave it blank. For an omitted
argument, @ref PAGE_MYSQLTEST "mysqltest" uses an empty string
for the first five arguments and the <b><em>options</em></b>
argument. For omitted port or socket options, @ref
PAGE_MYSQLTEST "mysqltest" uses the default port or socket.
@verbatim
connect (conn1,localhost,root,,);
connect (conn2,localhost,root,mypass,test);
connect (conn1,127.0.0.1,root,,test,$MASTER_MYPORT);
@endverbatim
The last example assumes that the <b>$MASTER_MYPORT</b> variable
has already been set (perhaps as an environment variable).
If a connection attempt fails initially, @ref PAGE_MYSQLTEST
"mysqltest" retries five times if the abort-on-error setting is
enabled.
</li>
<li>
<tt>connection <b>connection_name</b></tt>
Select <b><em>connection_name</em></b> as the current
connection. To select the connection that @ref PAGE_MYSQLTEST
"mysqltest" opens when it starts, use the name default.
@verbatim
connection master;
connection conn2;
connection default;
@endverbatim
A variable can be used to specify the
<b><em>connection_name</em></b> value.
</li>
<li>
<tt>let $var= convert_error(<b>error</b>)</tt>
This is not a command as such but rather a function that can be
used in <b>let</b> statements. If the argument is a number, it
returns the name of the corresponding error, or <b>\<Unknown\></b>
if no such error exists. If the argument is an error name, it
returns the corresponding number, or fails if the error name is
unknown. If the argument is 0 or an empty string, it returns 0.
The function can also take a variable as argument.
@verbatim
let $errvar1=convert_error(ER_UNKNOWN_ERROR);
let $errvar2=convert_error(1450);
let $errvar3=convert_error($errvar1);
@endverbatim
</li>
<li>
<tt>copy_file <b>from_file to_file</b> [<b>retry</b>]</tt>
Copy the file <b><em>from_file</em></b> to the file
<b><em>to_file</em></b>. The command fails if
<b><em>to_file</em></b> already exists. The file name arguments
are subject to variable substitution.
<b>copy_file</b> can also take an optional argument <b>retry</b>.
If the command fails due to an environmental issue, the command
can be retried for a <b>retry</b> number of times. Each retry
happens after an interval of one second.
@verbatim
copy_file $MYSQL_TMP_DIR/copy1.txt $MYSQL_TMP_DIR/copy2.txt;
copy_file $MYSQL_TMP_DIR/foo.txt $MYSQL_TMP_DIR/foo2.txt 5;
@endverbatim
</li>
<li>
<tt>copy_files_wildcard <b>src_dir_name dst_dir_name</b>
<b>pattern</b> [<b>retry</b>]</tt>
Copy all files that match the pattern in the source directory to
the destination directory. Patterns can use <b>?</b> to
represent any single character, or <b>*</b> for any sequence of
0 or more characters. The <b>.</b> character is treated like any
other. The pattern may not include <b>/</b>. If all the files
need to be copied, the <b>*</b> wildcard can be used.
<b>copy_files_wildcard</b> can also take an optional argument
<b>retry</b>. If the command fails due to an environmental
issue, the command can be retried for a <b>retry</b> number
of times. Each retry happens after an interval of one second.
The command works like this:
<ul>
<li>
Files that match the pattern are copied from the source
directory to the destination directory. Overwriting of files
is permitted.
</li>
<li>
Copying does not apply to directories matching the pattern
or matching files in subdirectories.
</li>
<li>
If the source or destination directory is not present, an
error occurs.
</li>
<li>
If no files match the specified pattern, an error occurs.
</li>
<li>
If the source directory has no files, an error occurs.
</li>
</ul>
@verbatim
copy_files_wildcard $MYSQLTEST_VARDIR/std_data/ $MYSQLTEST_VARDIR/copy1/ *.txt;
copy_files_wildcard $MYSQLTEST_VARDIR/std_data/ $MYSQLTEST_VARDIR/copy1/ *.txt 5;
@endverbatim
</li>
<li>
<tt>dec <b>$var_name</b></tt>
Decrement a numeric variable. If the variable does not have a
numeric value, the result is undefined.
@verbatim
dec $count;
dec $2;
@endverbatim
</li>
<li>
<tt>delimiter <b>str</b></tt>
Set the command delimiter to <b><em>str</em></b>, which may consist
of 1 to 15 characters. The default delimiter is the semicolon
character (“<b>;</b>”).
@verbatim
delimiter /;
--delimiter stop
@endverbatim
This is useful or needed when you want to include long SQL
statements like <b>CREATE PROCEDURE</b> which include semicolon
delimited statements but need to be interpreted as a single
statement by @ref PAGE_MYSQLTEST "mysqltest". If you have set
the delimiter to “<b>/</b>” as in the previous example, you can
set it back to the default like this:
@verbatim
delimiter ;|
@endverbatim
</li>
<li>
<tt>die [<b>message</b>]</tt>
Aborts the test with an error code after printing the given
message as the reason. Suppose that a test file contains the
following line:
@verbatim
die Cannot continue;
@endverbatim
When @ref PAGE_MYSQLTEST "mysqltest" encounters that line, it
produces the following result and exits:
@verbatim
mysqltest: At line 1: Cannot continue
not ok
@endverbatim
</li>
<li>
<tt>diff_files <b>file_name1 file_name2</b></tt>
Compare the two files. The command succeeds if the files are the
same, and fails if they are different or either file does not
exist. The file name arguments are subject to variable
substitution.
</li>
<li>
<tt>dirty_close <b>connection_name</b></tt>
Close the named connection. This is like <b>disconnect</b>
except that it calls <b>vio_delete()</b> before it closes the
connection. If the connection is the current connection, you
should use the <b>connection</b> command to switch to a
different connection before executing further SQL statements.
A variable can be used to specify the
<b><em>connection_name</em></b> value.
</li>
<li>
<tt>disable_abort_on_error</tt>, <tt>enable_abort_on_error</tt>
Disable or enable abort-on-error behavior. This setting is
enabled by default. With this setting enabled, @ref
PAGE_MYSQLTEST "mysqltest" aborts the test when a statement sent
to the server results in an unexpected error, and does not
generate the <b>.reject</b> file. For discussion of reasons why
it can be useful to disable this behavior, see @ref
PAGE_ERROR_HANDLING.
@verbatim
--disable_abort_on_error
--enable_abort_on_error
@endverbatim
</li>
<li>
<tt>disable_connect_log</tt>, <tt>enable_connect_log</tt>
Disable or enable logging of creation or switch of connections.
Connection logging is disabled by default. With this setting
enabled, @ref PAGE_MYSQLTEST "mysqltest" enters lines in the
test results to show when connections are created, switched or
disconnected.
If query logging is turned off using <b>disable_query_log</b>,
connection logging is also turned off, until query log is re-
enabled.
@verbatim
--disable_connect_log
--enable_connect_log
@endverbatim
</li>
<li>
<tt>disable_info</tt>, <tt>enable_info</tt>
Disable or enable additional information about SQL statement
results. Information display is disabled by default. With this
setting enabled, @ref PAGE_MYSQLTEST "mysqltest" displays the
affected-rows count and the output from the <b>mysql_info()</b>
C API function. The “affected-rows” value is “rows selected” for
statements such as <b>SELECT</b> and “rows modified” for
statements that change data.
@verbatim
--disable_info
--enable_info
@endverbatim
</li>
<li>
<tt>disable_metadata</tt>, <tt>enable_metadata</tt>
Disable or enable query metadata display. Metadata display is
disabled by default. With this setting enabled, @ref
PAGE_MYSQLTEST "mysqltest" adds query metadata to the result.
This information consists of the values corresponding to the
members of the <b>MYSQL_FIELD</b> C API data structure, for each
column of the result.
@verbatim
--disable_metadata
--enable_metadata
@endverbatim
</li>
<li>
<tt>disable_ps_protocol</tt>, <tt>enable_ps_protocol</tt>
Disable or enable prepared-statement protocol. This setting is
disabled by default unless the <b>`--ps-protocol`</b> option is
given.
@verbatim
--disable_ps_protocol
--enable_ps_protocol
@endverbatim
</li>
<li>
<tt>disable_query_log</tt>, <tt>enable_query_log</tt>
Disable or enable query logging. This setting is enabled by
default. With this setting enabled, @ref PAGE_MYSQLTEST
"mysqltest" echoes input SQL statements to the test result.
One reason to disable query logging is to reduce the amount of
test output produced, which also makes comparison of actual and
expected results more efficient.
@verbatim
--disable_query_log
--enable_query_log
@endverbatim
</li>
<li>
<tt>disable_reconnect</tt>, <tt>enable_reconnect</tt>
Disable or enable automatic reconnect for dropped connections.
(The default depends on the client library version.) This
command only applies to the current connection.
@verbatim
--disable_reconnect
--enable_reconnect
@endverbatim
</li>
<li>
<tt>disable_result_log</tt>, <tt>enable_result_log</tt>
Disable or enable the result log. This setting is enabled by
default. With this setting enabled, @ref PAGE_MYSQLTEST
"mysqltest" displays query results (and results from commands
such as <b>echo</b> and <b>exec</b>).
@verbatim
--disable_result_log
--enable_result_log
@endverbatim
</li>
<li>
<tt>disable_rpl_parse</tt>, <tt>enable_rpl_parse</tt>
Disable or enable parsing of statements to determine whether
they go to the master or slave. The default is whatever the
default is for the C API library.
@verbatim
--disable_rpl_parse
--enable_rpl_parse
@endverbatim
</li>
<li>
<tt>disable_session_track_info</tt>, <tt>enable_session_track_info</tt>
Disable or enable display of session tracking information.
Session-tracking display disabled by default.
@verbatim
--disable_session_track_info
--enable_session_track_info
@endverbatim
</li>
<li>
<tt>disable_testcase bug_number</tt>, <tt>enable_testcase</tt>
Disable or enable a section from a test case. This setting is
enabled by default. When disabled, @ref PAGE_MYSQLTEST
"mysqltest" ignores everything until <b>enable_testcase</b>.
These commands are useful for disabling a section inside a
<b>.test</b> file that fails due to a known bug, without having
to disable the entire test case.
Bug number is a mandatory argument to <b>disable_testcase</b>
command and it should be in <b>BUG\#XXXX</b> format where keyword
<b>BUG</b> is case-insensitive and <b>XXXX</b> should contain
only digits.
@verbatim
--disable_testcase BUG#XXXX
--enable_testcase
@endverbatim
</li>
<li>
<tt>disable_warnings</tt>, <tt>enable_warnings</tt>
Disable or enable warnings. This setting is enabled by default.
With this setting enabled, @ref PAGE_MYSQLTEST "mysqltest" uses
<b>SHOW WARNINGS</b> to display any warnings produced by SQL
statements.
@verbatim
--disable_warnings
--enable_warnings
@endverbatim
<b>disable_warnings</b> and <b>enable_warnings</b> commands can
take an optional argument specifying one or more comma-separated
list of warnings to be disabled or enabled. Each warning
specified should be in symbolic error name format.
@verbatim
--disable_warnings ER_BAD_TABLE_ERROR,ER_YES
DROP TABLE IF EXISTS t1;
--enable_warnings ER_BAD_TABLE_ERROR,ER_YES
@endverbatim
Or
@verbatim
--disable_warnings
DROP TABLE IF EXISTS t1;
--enable_warnings ER_BAD_TABLE_ERROR,ER_YES
DROP TABLE IF EXISTS t1;
--disable_warnings ER_BAD_TABLE_ERROR,ER_YES
--enable_warnings
@endverbatim
<b>disable_warnings</b> and <b>enable_warnings</b> commands can
also take a second optional argument, <b>"ONCE"</b>, which when
specified will disable or enable the warnings for next
statement only.
@verbatim
--disable_warnings ER_BAD_TABLE_ERROR ONCE
DROP TABLE IF EXISTS t1;
@endverbatim
Or
@verbatim
--disable_warnings
DROP TABLE IF EXISTS t1;
--enable_warnings ER_BAD_TABLE_ERROR ONCE
DROP TABLE IF EXISTS t1;
--enable_warnings
@endverbatim
</li>
@note
At the end of a test, all the disabled warnings must be enabled,
else @ref PAGE_MYSQLTEST "mysqltest" will throw an error and
abort the test run.
<li>
<tt>disconnect <b>connection_name</b></tt>
Close the named connection. If the connection is the current
connection, you should use the <b>connection</b> command to
switch to a different connection before executing further SQL
statements.
@verbatim
disconnect conn2;
disconnect slave;
@endverbatim
</li>
<li>
<tt>echo <b>text</b></tt>
Echo the text to the test result. References to variables within
the text are replaced with the corresponding values. The text
does not need to be enclosed in quotation marks; if it is, the
quotation marks will be included in the output.
@verbatim
--echo Another sql_mode test
echo should return only 1 row;
@endverbatim
</li>
<li>
<tt>end</tt>
End an <b>if</b> or <b>while</b> block. If there is no such
block open, @ref PAGE_MYSQLTEST "mysqltest" exits with an error.
See @ref PAGE_MYSQL_TEST_FLOW_CONTROL, for information on
flow-control constructs.
@ref PAGE_MYSQLTEST "mysqltest" considers <b>}</b> and end the
same: Both end the current block.
</li>
<li>
<tt>end_timer</tt>
Stop the timer. By default, the timer does not stop until just
before @ref PAGE_MYSQLTEST "mysqltest" exits.
</li>
<li>
<tt>error <b>error_code</b> [, <b>error_code</b>] ...</tt>
Specify one or more comma-separated error values that the next
command is expected to return. Each <b><em>error_code</em></b>
value is a MySQL-specific error number or an <b>SQLSTATE</b>
value. (These are the kinds of values returned by the
<b>mysql_errno()</b> and <b>mysql_sqlstate()</b> C API
functions, respectively.)
If you specify an <b>SQLSTATE</b> value, it should begin with an
<b>S</b> to enable @ref PAGE_MYSQLTEST "mysqltest" to
distinguish it from a MySQL error number. For example, the error
number 1050 and the SQLSTATE value <b>42S01</b> are equivalent,
so the following commands specify the same expected error:
@verbatim
--error 1050
--error S42S01
@endverbatim
<b>SQLSTATE</b> values should be five characters long and may
contain only digits and uppercase letters.
It is also possible to use the symbolic error name from
<b>mysqld_error.h</b>:
@verbatim
--error ER_TABLE_EXISTS_ERROR
@endverbatim
It is also possible to use symbolic error names from
<b>errmsg.h</b> to refer to client errors:
@verbatim
--error CR_SERVER_GONE_ERROR
@endverbatim
Finally, you can assign either a numerical code or a symbolic
error name to a variable and refer to that in the <b>error</b>
command. Numbers, symbolic names and variables may be freely
mixed.
If a statement fails with an error that has not been specified
as expected by means of a <b>error</b> command, @ref
PAGE_MYSQLTEST "mysqltest" aborts and reports the error message
returned by the MySQL server.
If a statement fails with an error that has been specified as
expected by means of a <b>error</b> command, @ref PAGE_MYSQLTEST
"mysqltest" does not abort. Instead, it continues and writes a
message to the result output.
<ul>
<li>
If an <b>error</b> command is given with a single error
value and the statement fails with that error, @ref
PAGE_MYSQLTEST "mysqltest" reports the error message
returned by the MySQL server.
Input:
@verbatim
--error S42S02
DROP TABLE t;
@endverbatim
@ref PAGE_MYSQLTEST "mysqltest" reports:
@verbatim
ERROR 42S02: Unknown table 't'
@endverbatim
</li>
<li>
If an <b>error</b> command is given with multiple error
values and the statement fails with any of those errors,
@ref PAGE_MYSQLTEST "mysqltest" reports a generic message.
(This is true even if the error values are all the same, a
fact that can be used if you want a message that does not
contain varying information such as table names.)
Input:
@verbatim
--error S41S01,S42S02
DROP TABLE t;
@endverbatim
@ref PAGE_MYSQLTEST "mysqltest" reports:
@verbatim
Got one of the listed errors
@endverbatim
</li>
</ul>
An error value of <b>0</b> or <b>S00000</b> means “no error,”
so using either for an <b>error</b> command is the same as saying
explicitly, “no error is expected, the statement must succeed.”.
To indicate that you expect success or a given error or errors,
specify <b>0</b> or <b>S00000</b> first in the error list. If
you put the no-error value later in the list, the test will abort
if the statement is successful. That is, the following two commands
have different effects: The second form literally means the next
command may fail with error code 0, (rather than succeed) which
in practice never happens:
@verbatim
--error 0,1051
--error 1051,0
@endverbatim
You can use <b>error</b> to specify shell status values for
testing the value of shell commands executed using the
<b>exec</b> command. This does not apply to <b>system</b>, for
which the command status is ignored.
If you use <b>error</b> in combination with <b>send</b> and
<b>reap</b>, the <b>error</b> should be used just before the
<b>reap</b>, as this is the command that actually gives the
result and the potential error.
Variables may also be used as arguments to the <b>error</b>
command; these may contain a number (including 0), an SQLSTATE
or a symbolic error name. Variables and constant values may be
freely combined.
</li>
<li>
<tt>eval <b>statement</b></tt>
Evaluate the statement by replacing references to variables
within the text with the corresponding values. Then send the
resulting statement to the server to be executed. Use
“<b>\$</b>” to specify a literal “<b>$</b>” character.
The advantage of using <b>eval <em>statement</em></b> versus just
<b><em>statement</em></b> is that <b>eval</b> provides variable
expansion.
@verbatim
eval USE $DB;
eval CHANGE MASTER TO MASTER_PORT=$SLAVE_MYPORT;
eval PREPARE STMT1 FROM "$my_stmt";
@endverbatim
</li>
<li>
<tt>exec <b>command</b> [<b>arg</b>] ...</tt>
Execute the shell command using the <b>popen()</b> library call.
References to variables within the command are replaced with the
corresponding values. Use “<b>\\$</b>” to specify a literal
“<b>$</b>” character.
On Cygwin, the command is executed from <b>cmd.exe</b>, so
commands such as <b>rm</b> cannot be executed with <b>exec</b>.
Use <b>system</b> instead.
@verbatim
--exec $MYSQL_DUMP --xml --skip-create test
--exec rm $MYSQLTEST_VARDIR/tmp/t1
exec $MYSQL_SHOW test -v -v;
@endverbatim
@note
<b>exec</b> or <b>system</b> are sometimes used to perform
file system operations, but the command for doing so tend to be
operating system specific, which reduces test portability. @ref
PAGE_MYSQLTEST "mysqltest" now has several commands to perform
these operations portably, so they should be used instead:
<b>remove_file</b>, <b>chmod</b>, <b>mkdir</b>, and so forth.
</li>
<li>
<tt>exec_in_background <b>command</b> [<b>arg</b>] ...</tt>
Execute a shell command using the <b>popen()</b> library call in
the background. When a command is executed using
<b>exec_in_background</b>, @ref PAGE_MYSQLTEST "mysqltest" does
not wait for it to finish, nor attempt to read the output of it.
@verbatim
--exec_in_background $MYSQL_DUMP --xml --skip-create test
--exec_in_background rm $MYSQLTEST_VARDIR/tmp/t1
@endverbatim
</li>
<li>
<tt>execw <b>command</b> [<b>arg</b>] ...</tt>
This is a variant of the <b>exec</b> command which is needed on
Windows if the command line contains non-ASCII characters.
Otherwise it works exactly the same. On platforms other than
Windows there is no difference, but on Windows it uses a
different version of the <b>popen()</b> library call. So if your
command line contains non-ASCII characters, it is recommended to
use <b>execw</b> instead of <b>exec</b>.
</li>
<li>
<tt>exit</tt>
Terminate the test case. This is considered a “normal
termination.” That is, using <b>exit</b> does not result in
evaluation of the test case as having failed. It is not
necessary to use <b>exit</b> at the end of a test case, as the
test case will terminate normally when reaching the end without
failure.
</li>
<li>
<tt>expr <b>$var_name</b>= <b>operand1 operator operand2</b></tt>
Evaluate an expression and assign the result to a variable. The
result is also the return value of the expr command itself.
@verbatim
--let $val1= 10
--let $var2= 20
--expr $res= $var1 + $var2
--echo $res
@endverbatim
<b>operand1</b> and <b>operand2</b> must be valid variables.
expr supports these mathematical operators:
@verbatim
+ Addition
- Subtraction
* Multiplication
/ Division
% Modulo
@endverbatim
expr supports these logical operators:
@verbatim
&& Logical AND
|| Logical OR
@endverbatim
expr supports these bitwise operators:
@verbatim
& Binary AND
| Binary OR
^ Binary XOR
<< Binary left shift
>> Binary right shift
@endverbatim
Operations are subject to these conditions:
- Operations that do not support noninteger operands truncate
such operands to integer values.
- If the result is an infinite value, expr returns the inf
keyword.
- Division by 0 results in an infinite value.
</li>
<li>
<tt>file_exists <b>file_name</b> [<b>retry</b>]</tt>
<b>file_exists</b> succeeds if the named file exists and fails
otherwise. The file name argument is subject to variable
substitution.
<b>file_exists</b> can also take an optional argument
<b>retry</b>. If the command fails due to an environmental
issue, the command can be retried for a <b>retry</b> number
of times. Each retry happens after an interval of one second.
@verbatim
file_exists /etc/passwd;
file_exists /etc/passwd 5;
@endverbatim
</li>
<li>
<tt>force-cpdir <b>src_dir_name dst_dir_name</b></tt>
Copies the source directory, <b><em>src_dir_name</em></b>, to
the destination directory, <b><em>dst_dir_name</em></b>. The
copy operation is recursive, so it copies subdirectories.
Returns 0 for success and 1 for failure.
@verbatim
--force-cpdir testdir testdir2
@endverbatim
If the source directory does not exist, an error occurs.
If the destination directory does not exist, @ref PAGE_MYSQLTEST
"mysqltest" creates it before copying the source directory.
</li>
<li>
<tt>force-rmdir <b>dir_name</b></tt>
Remove a directory named <b><em>dir_name</em></b>. Returns 0 for
success and 1 for failure.
@verbatim
--force-rmdir testdir
@endverbatim
<b>force-rmdir</b> removes the directory as well as its
contents, if any, unlike <b>rmdir</b>, which fails if the
directory to be removed contains any files or directories.
</li>
<li>
<tt>horizontal_results</tt>
Set the default query result display format to horizontal.
Initially, the default is to display results horizontally.
@verbatim
--horizontal_results
@endverbatim
</li>
<li>
<tt>if (<b>expr</b>)</tt>
Begin an if block, which continues until an <b>end</b> or
<b>}</b> line. @ref PAGE_MYSQLTEST "mysqltest" executes the
block if the expression is non-zero. There is no provision for
<b>else</b> with <b>if</b>. See @ref
PAGE_MYSQL_TEST_FLOW_CONTROL, for further information about
<b>if</b> statements.
@verbatim
let $counter= 0;
if ($counter)
{
echo Counter is not 0;
}
if (!$counter)
{
echo Counter is 0;
}
@endverbatim
</li>
<li>
<tt>inc <b>$var_name</b></tt>
Increment a numeric variable. If the variable does not have a
numeric value, the result is undefined.
@verbatim
--inc $i;
inc $3;
@endverbatim
</li>
<li>
<tt>let <b>$var_name</b> = <b>value</b></tt>
<tt>let <b>$var_name</b> = query_get_value(<b>query</b>,
<b>col_name</b>,
<b>row_num</b>)</tt>
Assign a value to a variable. The variable name cannot contain
whitespace or the “<b>=</b>” character. Except for the one-digit
<b>$0</b> to <b>$9</b>, it cannot begin with a number. @ref
PAGE_MYSQLTEST "mysqltest" aborts with an error if the value is
erroneous.
References to variables within <b><em>value</em></b> are replaced
with their corresponding values.
If the <b>let</b> command is specified as a normal command (that
is, not beginning with “<b>--</b>”), <b><em>value</em></b>
includes everything up to the command delimiter, and thus can
span multiple lines.
@verbatim
--let $1= 0
let $count= 10;
@endverbatim
When assigning a literal string to a variable, no quoting is
required even if the string contains spaces. If the string does
include quotation marks, they will be trated like any other
characters and be included in the string value. This is
important to be aware of when using the variable in an SQL
statement.
The result from executing a query can be assigned to a variable
by enclosing the query within backtick (“`”) characters:
@verbatim
let $q= `SELECT VERSION()`;
@endverbatim
The <b>let</b> command can set environment variables, not just
@ref PAGE_MYSQLTEST "mysqltest" test language variables. To
assign a value to an environment variable rather than a test
language variable, just omit the dollar sign:
@verbatim
let $mysqltest_variable= foo;
let ENV_VARIABLE= bar;
@endverbatim
This is useful in interaction with external tools. In
particular, when using the <b>perl</b> command, the Perl code
cannot access test language variables, but it can access
environment variables. For example, the following statement can
access the <b>ENV_VARIABLE</b> value:
@verbatim
print $ENV{'ENV_VARIABLE'};
@endverbatim
The <b>let</b> syntax also allows the retrieval of a value from
a query result set produced by a statement such as <b>SELECT</b>
or <b>SHOW</b>. See the description of <b>query_get_value()</b>
for more information.
</li>
<li>
<tt>mkdir <b>dir_name</b></tt>
Create a directory named <b><em>dir_name</em></b>. Returns 0 for
success and 1 for failure.
@verbatim
--mkdir testdir
@endverbatim
</li>
<li>
<tt>list_files <b>dir_name</b> [<b>pattern</b>]</tt>
<b>list_files</b> lists the files in the named directory. If a
pattern is given, lists only file(s) matching the pattern, which
may contain wild cards.
@verbatim
--list_files $MYSQLD_DATADIR/test t1*
@endverbatim
</li>
<li>
<tt>list_files_append_file <b>file_name dir_name</b>
[<b>pattern</b>]</tt>
<b>list_files_append_file</b> works like <b>list_files</b>,
but rather than outputting the file list, it is appended to the
file named in the first argument. If the file does not exist, it
is created.
@verbatim
--list_files_append_file $MYSQL_TMP_DIR/filelist $MYSQL_TMP_DIR/testdir *.txt;
@endverbatim
</li>
<li>
<tt>list_files_write_file <b>file_name dir_name</b>
[<b>pattern</b>]</tt>
<b>list_files_write_file</b> works like
<b>list_files_append_file</b>, but creates a new file to write
the file list to. If the file already exists, it will be
replaced.
@verbatim
--list_files_write_file $MYSQL_TMP_DIR/filelist $MYSQL_TMP_DIR/testdir *.txt;
@endverbatim
</li>
<li>
<tt>lowercase_result</tt>
Output from the following SQL statement will be converted to
lowercase. This is sometimes needed to ensure consistent result
across different platforms. If this is combined with one of the
<b>replace</b> commands or with <b>sorted_result</b>, both will
take effect on the output, with conversion to lowercase being
applied first.
@verbatim
--lowercase_result
@endverbatim
</li>
<li>
<tt>move_file <b>from_name to_name</b> [<b>retry</b>]</tt>
<b>move_file</b> renames <b><em>from_name</em></b> to
<b><em>to_name</em></b>. The file name arguments are subject to
variable substitution, but must evaluate to a literal file name,
not a file name pattern.
<b>move_file</b> can also take an optional argument <b>retry</b>.
If the command fails due to an environmental issue, the command
can be retried for a <b>retry</b> number of times. Each retry
happens after an interval of one second.
@verbatim
move_file $MYSQL_TMP_DIR/data01 $MYSQL_TMP_DIR/test.out;
move_file $MYSQL_TMP_DIR/data01 $MYSQL_TMP_DIR/test.out 5;
@endverbatim
</li>
<li>
<tt>output <b>file_name</b></tt>
Direct output from the next SQL statement to the named file
rather than to the test output. If the file already exists, it
will be overwritten. Only the next SQL statement will have its
output redirected.
@verbatim
output $MYSQL_TMP_DIR/out-file
@endverbatim
</li>
<li>
<tt>perl [<b>terminator</b>]</tt>
Use Perl to execute the following lines of the test file. The
lines end when a line containing the terminator is encountered.
The default terminator is <b>EOF</b>, but a different terminator
can be provided.
@verbatim
perl;
print "This is a test\n";
EOF
@endverbatim
@verbatim
perl END_OF_FILE;
print "This is another test\n";
END_OF_FILE
@endverbatim
</li>
<li>
<tt>ping</tt>
Ping the server. This executes the <b>mysql_ping()</b> C API
function. The function result is discarded. The effect is that
if the connection has dropped and reconnect is enabled, pinging
the server causes a reconnect.
</li>
<li>
<tt>query [<b>statement</b>]</tt>
Send the statement to the server to be executed. The
<b>query</b> command can be used to force @ref PAGE_MYSQLTEST
"mysqltest" to send a statement to the server even if it begins
with a keyword that is a @ref PAGE_MYSQLTEST "mysqltest"
command.
</li>
<li>
<tt>query_get_value(<b>query</b>, <b>col_name</b>, <b>row_num</b>)</tt>
The <b>query_get_value()</b> function can be used only on the
right hand side of a variable assigment in a <b>let</b>
statement.
<b>query_get_value()</b> enables retrieval of a value from a
query result set produced by a statement such as <b>SELECT</b>
or <b>SHOW</b>. The first argument indicates the query to
execute. The second and third arguments indicate the column name
and row number that specify which value to extract from the
result set. The column name is case sensitive. Row numbers begin
with 1. The arguments can be given literally or supplied using
variables.
Suppose that the test file contains this input:
@verbatim
CREATE TABLE t1(a INT, b VARCHAR(255), c DATETIME);
SHOW COLUMNS FROM t1;
let $value= query_get_value(SHOW COLUMNS FROM t1, Type, 1);
echo $value;
@endverbatim
The result will be:
@verbatim
CREATE TABLE t1(a INT, b VARCHAR(255), c DATETIME);
SHOW COLUMNS FROM t1;
Field Type Null Key Default Extra
a int(11) YES NULL
b varchar(255) YES NULL
c datetime YES NULL
int(11)
@endverbatim
If the query fails, an error message occurs and the test fails.
</li>
<li>
<tt>query_horizontal <b>statement</b></tt>
Execute the statement and display its result horizontally.
@verbatim
query_horizontal SELECT PI();
@endverbatim
</li>
<li>
<tt>query_vertical <b>statement</b></tt>
Execute the statement and display its result vertically.
@verbatim
query_vertical SELECT PI();
@endverbatim
</li>
<li>
<tt>real_sleep <b>num</b></tt>
Sleep <b><em>num</em></b> seconds. <b><em>num</em></b> can have
a fractional part. Unlike the <b>sleep</b> command,
<b>real_sleep</b> is not affected by the
<b>`--sleep command-line`</b> option.
@verbatim
--real_sleep 10
real_sleep 5;
@endverbatim
Try not to use <b>sleep</b> or <b>real_sleep</b> commands more
than necessary. The more of them there are, the slower the test
suite becomes.
</li>
<li>
<tt>reap</tt>
Receive the result of the statement sent with the <b>send</b>
command within the current session. You should not use
<b>reap</b> unless a statement has been sent with <b>send</b>,
and you should not use <b>send</b> again if there is an
outstanding <b>send</b> that has not been processed with
<b>reap</b>.
</li>
<li>
<tt>remove_file <b>file_name</b> [<b>retry</b>]</tt>
<b>remove_file</b> removes the file. It fails with an error if
the file does not exist. The file name argument is subject to
variable substitution, but must evaluate to a literal file name,
not a file name pattern.
<b>remove_file</b> also takes an optional argument <b>retry</b>.
If the command fails due to an environmental issue, the command
can be retried for a <b>retry</b> number of times. Each retry
happens after an interval of one second.
@verbatim
remove_file $MYSQL_TMP_DIR/data01;
remove_file $MYSQL_TMP_DIR/data01 5
@endverbatim
</li>
<li>
<tt>remove_files_wildcard <b>dir_name</b> <b>pattern</b> [<b>retry</b>]</tt>
Remove all files in the named directory that match the pattern.
Removal does not apply to directories matching the pattern or
matching files in subdirectories. Patterns can use <b>?</b> to
represent any single character, or <b>*</b> for any sequence of
0 or more characters. The <b>.</b> character is treated like any
other. The pattern may not include <b>/</b>. If all the files
need to be removed, the <b>*</b> wildcard can be used.
<b>remove_files_wildcard</b> can also take an optional argument
<b>retry</b>. If the command fails due to an environmental
issue, the command can be retried for a <b>retry</b> number of
times. Each retry happens after an interval of one second.
@verbatim
remove_files_wildcard $MYSQL_TMP_DIR file*.txt;
remove_files_wildcard $MYSQL_TMP_DIR file*.txt 5;
@endverbatim
</li>
<li>
<tt>replace_column <b>col_num</b> <b>value</b>
[<b>col_num value</b>] ...</tt>
Replace strings in the output from the next statement. The value
in <b><em>col_num</em></b> is replaced by the corresponding
<b><em>value</em></b>. There can be more than one
<b><em>col_num/value</em></b> pair. Column numbers start with 1.
A replacement value can be double-quoted. (Use “<b>\"</b>” to
specify a double quote within a replacement string.) Variables
can be used in a replacement value if it is not double-quoted.
If mixed <b>replace_<em>xxx</em></b> commands are given, only the
final one applies.
@note
Although <b>replace_regex</b> and <b>replace_result</b> affect
the output from <b>exec</b>, <b>replace_column</b> does not
because <b>exec</b> output is not necessarily columnar.
@verbatim
--replace_column 9 #
replace_column 1 b 2 d;
@endverbatim
</li>
<li>
<tt>replace_numeric_round <b>precision</b></tt>
Rounds off floating point numbers. <b>precision</b> is the
number of digits after the decimal point to which the result will
be rounded off to. It can only be a number between
0 and 16.
If the precision is 0, then the value is rounded off to the
nearest whole number. Trailing zeroes after the decimal point are
removed from the numbers.
Numbers which are <b>greater than <em>1e10</em></b> or <b> lesser
than <em> -1e10 </em></b> are represented using the
exponential notation after they are rounded off.
@verbatim
--replace_numeric_round 6
SELECT 12379.79459775333;
12379.794598
replace_numeric_round 0;
SELECT 876.87302;
877
@endverbatim
</li>
<li>
<tt>replace_regex <b>/pattern/replacement/</b>[i] ...</tt>
In the output from the next statement, find strings within
columns of the result set that match <b><em>pattern</em></b> (a
regular expression) and replace them with
<b><em>replacement</em></b>. Each instance of a string in a
column that matches the pattern is replaced. Matching is case
sensitive by default. Specify the optional <b>i</b> modifier to
cause matching to be case insensitive.
The syntax for allowable patterns is same as the <b>std::ECMAScript</b>
syntax. The pattern can contain parentheses to mark substrings
matched by parts of the pattern. These substrings can be referenced in
the replacement string: An instance of <b><em>N</em></b> in the
replacement string causes insertion of the <b><em>N</em>-th</b> substring
matched by the pattern. For example, the following command matches
<b>strawberry</b> and replaces it with <b>raspberry</b> and
<b>strawberry</b>:
@verbatim
--replace_regex /(strawberry)/raspberry and \1/
@endverbatim
Multiple <b><em>pattern/replacement</em></b> pairs may be given.
The following command replaces instances of <b>A</b> with
<b>C</b> (the first pattern replaces <b>A</b> with <b>B</b>, the
second replaces <b>B</b> with <b>C</b>):
@verbatim
--replace_regex /A/B/ /B/C/
@endverbatim
If a given pattern is not found, no error occurs and the input
is unchanged.
</li>
<li>
<tt>replace_result <b>from_val to_val</b>
[<b>from_val to_val</b>] ...</tt>
Replace strings in the result. Each occurrence of
<b><em>from_val</em></b> is replaced by the corresponding
<b><em>to_val</em></b>. There can be more than
<b><em>from_val/to_val</em></b> pair. Arguments can be quoted
with single quotation marks or double quotation marks. Variable
references within the arguments are expanded before replacement
occurs. Values are matched literally. To use patterns, use the
<b>replace_regex</b> command.
@verbatim
--replace_result 1024 MAX_KEY_LENGTH 3072 MAX_KEY_LENGTH
replace_result $MASTER_MYPORT MASTER_PORT;
@endverbatim
</li>
<li>
<tt>reset_connection</tt>
Reset the connection state by calling [mysql_reset_connection()]
(https://dev.mysql.com/doc/refman/8.0/en/mysql-reset-connection.html).
</li>
<li>
<tt>result_format <b>version</b></tt>
Set the format to the specified version, which is either 1 for
the current, default behavior, or to 2 which is an extended
alternative format. The setting is in effect until it is changed
or until the end of the test.
In format version 2, empty lines and indentation in the test
file are preserveded in the result. Also, comments indicated by
a double \## are copied verbatim to the result. Comments using a
single \# are not copied. Format version 2 makes it easier for
humans to read the result output, but at the cost of somewhat
larger files due to the white space and comments.
@verbatim
--result_format 2
@endverbatim
</li>
<li>
<tt>rmdir <b>dir_name</b></tt>
Remove a directory named <b><em>dir_name</em></b>. Returns 0 for
success and 1 for failure.
@verbatim
--rmdir testdir
@endverbatim
<b>rmdir</b> fails if the directory to be removed contains any
files or directories. To remove the directory as well as its
contents, if any, use <b>force-rmdir</b>.
</li>
<li>
<tt>save_master_pos</tt>
For a master replication server, save the current binary log
file name and position. These values can be used for subsequent
<b>sync_with_master</b> or <b>sync_slave_with_master</b>
commands.
</li>
<li>
<tt>send [<b>statement</b>]</tt>
Send a statement to the server but do not wait for the result.
The result must be received with the <b>reap</b> command. You
cannot execute another SQL statement on the same connection
between <b>send</b> and <b>reap</b>.
If <b><em>statement</em></b> is omitted, the <b>send</b> command
applies to the next statement executed. This means that
<b>send</b> can be used on a line by itself before a statement.
Thus, this command:
@verbatim
send SELECT 1;
@endverbatim
Is equivalent to these commands:
@verbatim
send;
SELECT 1;
@endverbatim
</li>
<li>
<tt>send_eval [<b>statement</b>]</tt>
Evaluate the command, then send it to the server. This is a
combination of the <b>send</b> and <b>eval</b> commands, giving
the functionality of both. After variable replacement has been
done, it behaves like the <b>send</b> command.
If <b><em>statement</em></b> is omitted, the <b>send_eval</b>
command applies to the next statement executed. This means that
<b>send_eval</b> can be used on a line by itself before a
statement. Thus, this command:
@verbatim
--send_eval $my_stmt
@endverbatim
</li>
Is equivalent to these commands:
@verbatim
--send_eval
$my_stmt;
@endverbatim
</li>
<li>
<tt>send_quit <b>connection</b></tt>
Sends a <b>COM_QUIT</b> command to the server on the named
connection.
@verbatim
send_quit con;
@endverbatim
</li>
<li>
<tt>send_shutdown</tt>
Sends a shutdown command to the server but does not wait for it
to complete the shutdown. Test execution proceeds as soon as the
shutdown command is sent.
</li>
<li>
<tt>shutdown_server [<b>timeout</b>]</tt>
Stops the server. This command waits for the server to shut down
by monitoring its process ID (PID) file. If the server's process
ID file is not gone after <b><em>timeout</em></b> seconds, the
process will be killed. If <b><em>timeout</em></b> is omitted,
the default is 60 seconds.
@verbatim
shutdown_server;
shutdown_server 30;
@endverbatim
</li>
<li>
<tt>skip [<b>message</b>]</tt>
Skips the rest of the test file after printing the given message
as the reason. This can be used after checking a condition that
must be satisfied, as a way of performing an exit that displays
a reason. References to variables within the message are
replaced with the corresponding values. Suppose that the test
file <b>mytest.test</b> has these contents:
@verbatim
let $var= 0;
if (!$var)
{
skip value of \$var is '$var', skipping test;
}
echo This command is never reached;
@endverbatim
Executing @ref PAGE_MYSQLTEST "mysqltest" -x mytest.test yields
these results:
@verbatim
The test './mytest' is not supported by this installation
Detected in file ./mytest at line 4
reason: value of $var is '0', skipping test
@endverbatim
If the test is run from @ref PAGE_MYSQL_TEST_RUN_PL
"mysql-test-run.pl", you will instead see the test result as
<b>[ skipped ]</b> followed by the message.
@verbatim
main.mytest [ skipped ] value of $var is '0', skipping test
@endverbatim
</li>
<li>
<tt>sleep <b>num</b></tt>
Sleep <b><em>num</em></b> seconds. <b><em>num</em></b> can have
a fractional part. If the <b>`--sleep`</b> command-line option
was given, the option value overrides the value given in the
<b>sleep</b> command. For example, if @ref PAGE_MYSQLTEST
"mysqltest" is started with <b>`--sleep`=10</b>, the command
<b>sleep 15</b> sleeps 10 seconds, not 15.
@verbatim
--sleep 10
sleep 0.5;
@endverbatim
Try not to use <b>sleep</b> or <b>real_sleep</b> commands more
than necessary. The more of them there are, the slower the test
suite becomes.
</li>
<li>
<tt>sorted_result</tt>
Sort the output from the next statement if it produces a result
set. <b>sorted_result</b> is applied just before displaying the
result, after any other result modifiers that might have been
specified, such as <b>replace_result</b> or
<b>replace_column</b>. If the next statement produces no result
set, <b>sorted_result</b> has no effect because there is nothing
to sort.
@verbatim
sorted_result;
SELECT 2 AS "my_col" UNION SELECT 1;
let $my_stmt=SELECT 2 AS "my_col" UNION SELECT 1;
--sorted_result
eval $my_stmt;
--sorted_result
--replace_column 1 #
SELECT '1' AS "my_col1",2 AS "my_col2"
UNION
SELECT '2',1;
@endverbatim
<b>sorted_result</b> sorts the entire result of the next query.
If this involves constructs such as <b>UNION</b>, stored
procedures, or multi-statements, the output will be in a fixed
order, but all the results will be sorted together and might
appear somewhat strange.
The purpose of the <b>sorted_result</b> command is to produce
output with a deterministic order for a given set of result
rows. It is possible to use <b>ORDER BY</b> to sort query
results, but that can sometimes present its own problems. For
example, if the optimizer is being investigated for some bug,
<b>ORDER BY</b> might order the result but return an incorrect
set of rows. <b>sorted_result</b> can be used to produce sorted
output even in the absence of <b>ORDER BY</b>.
<b>sorted_result</b> is useful for eliminating differences
between test runs that may otherwise be difficult to compensate
for. Results without <b>ORDER BY</b> are not guaranteed to be
returned in any given order, so the result for a given query
might differ between test runs. For example, the order might
vary between different server versions, so a result file created
by one server might fail when compared to the result created by
another server. The same is true for different storage engines.
<b>sorted_result</b> eliminates these order differences by
producing a deterministic row order.
Other ways to eliminate differences from results without use of
<b>sorted_result</b> include:
- Remove columns from the select list to reduce variability in
the output
- Use aggregate functions such as <b>AVG()</b> on all columns
of the select list
- Use <b>ORDER BY</b>
The use of aggregate functions or <b>ORDER BY</b> may also have
the advantage of exposing other bugs by introducing additional
stress on the server. The choice of whether to use
<b>sorted_result</b> or <b>ORDER BY</b> (or perhaps both) may be
dictated by whether you are trying to expose bugs, or avoid
having them affect results. This means that care should be taken
with <b>sorted_result</b> because it has the potential of hiding
server bugs that result in true problems with result order.
</li>
<li>
<tt>partially_sorted_result <b>start_column</b></tt>
Similarly to <b>sorted_result</b>, but assumes that the first
<b>start_column</b> columns are already sorted, sorting only
on the remaining ones. This is useful if you wish to verify
a partial ordering property, e.g. that <b>SELECT a,b,c ORDER BY
a</b>. In this case, you could use <b>partially_sorted_result 1</b>
to sort only on b and c, giving deterministic results without
masking bugs where sorting on a column would not work correctly.
<tt>sorted_result</tt> is functionally equal to
<tt>partially_sorted_result 0</tt>.
</li>
<li>
<tt>source <b>file_name</b></tt>
Read test input from the named file.
If you find that several test case files contain a common
section of commands (for example, statements that create a
standard set of tables), you can put those commands in another
file and those test cases that need the file can include it by
means of a <b>source <em>file_name</em></b> command. This
enables you to write the code just once rather than in multiple
test cases.
Normally, the file name in the <b>source</b> command is relative
to the <b>mysql-test</b> directory because @ref PAGE_MYSQLTEST
"mysqltest" usually is invoked in that directory.
A sourced file can use <b>source</b> to read other files, but
take care to avoid a loop. The maximum nesting level is 16.
@verbatim
--source include/have_csv.inc
source include/varchar.inc;
@endverbatim
The file name can include variable references. Variables are
expanded including any quotation marks in the values, so
normally the values should not include quotation marks. Suppose
that <b>/tmp/junk</b> contains this line:
@verbatim
SELECT 'I am a query';
@endverbatim
The following example shows one way in which variable references
could be used to specify the file name:
@verbatim
let $dir= /tmp;
let $file= junk;
source $dir/$file;
@endverbatim
</li>
<li>
<tt>start_timer</tt>
Restart the timer, overriding any timer start that occurred
earlier. By default, the timer starts when @ref PAGE_MYSQLTEST
"mysqltest" begins execution.
</li>
<li>
<tt>sync_slave_with_master [<b>connection_name</b>]</tt>
Executing this command is equivalent to executing the following
commands:
@verbatim
save_master_pos;
connection connection_name;
sync_with_master 0;
@endverbatim
If <b><em>connection_name</em></b> is not specified, the
connection named <b>slave</b> is used.
The effect is to save the replication coordinates (binary log
file name and position) for the server on the current connection
(which is assumed to be a master replication server), and then
switch to a slave server and wait until it catches up with the
saved coordinates. Note that this command implicitly changes the
current connection.
A variable can be used to specify the
<b><em>connection_name</em></b> value.
</li>
<li>
<tt>sync_with_master <b>offset</b></tt>
For a slave replication server, wait until it has caught up with
the master. The position to synchronize to is the position saved
by the most recent <b>save_master_pos</b> command plus offset.
To use this command, <b>save_master_pos</b> must have been
executed at some point earlier in the test case to cause @ref
PAGE_MYSQLTEST "mysqltest" to save the master's replication
coordinates.
</li>
<li>
<tt>vertical_results</tt>
Set the default query result display format to vertical.
Initially, the default is to display results horizontally.
@verbatim
--vertical_results
@endverbatim
</li>
<li>
<tt>wait_for_slave_to_stop</tt>
Poll the current connection, which is assumed to be a connection
to a slave replication server, by executing <b>SHOW STATUS LIKE
'Slave_running'</b> statements until the result is <b>OFF</b>.
For information about alternative means of slave server control,
see @ref PAGE_WRITING_REPLICATION_TESTS.
</li>
<li>
<tt>while (<b>expr</b>)</tt>
Begin a <b>while</b> loop block, which continues until an
<b>end</b> line. @ref PAGE_MYSQLTEST "mysqltest" executes the
block repeatedly as long as the expression is true (non-zero).
See @ref PAGE_MYSQL_TEST_FLOW_CONTROL, for further information
about while statements.
Make sure that the loop includes some exit condition that
eventually occurs. This can be done by writing
<b><em>expr</em></b> so that it becomes false at some point.
@verbatim
let $i=5;
while ($i)
{
echo $i;
dec $i;
}
@endverbatim
</li>
<li>
<tt>write_file <b>file_name</b> [<b>terminator</b>]</tt>
Write the following lines of the test file to the given file,
until a line containing the terminator is encountered. The
default terminator is <tt>EOF</tt>, but a different terminator
can be provided. The file name argument is subject to variable
substitution. An error occurs if the file already exists.
@verbatim
write_file $MYSQL_TMP_DIR/data01;
line one for the file
line two for the file
EOF
@endverbatim
@verbatim
write_file $MYSQL_TMP_DIR/data02 END_OF_FILE;
line one for the file
line two for the file
END_OF_FILE
@endverbatim
</li>
</ul>
*/
###############################################################################
## mysqltest Variables
/**
@page PAGE_MYSQL_TEST_VARIABLES mysqltest Variables
You can define variables and refer to their values. You can also
refer to environment variables, and there is a built-in variable
that contains the result of the most recent SQL statement.
To define a variable, use the <b>let</b> command. Examples:
@verbatim
let $a= 14;
let $b= this is a string;
--let $a= 14
--let $b= this is a string
@endverbatim
The variable name cannot contain whitespace or the “=” character.
If a variable has a numeric value, you can increment or decrement
the value:
@verbatim
inc $a;
dec $a;
--inc $a
--dec $a
@endverbatim
<b>inc</b> and <b>dec</b> are commonly used in <b>while</b>
loops to modify the value of a counter variable that controls loop
execution.
The result from executing a query can be assigned to a variable by
enclosing the query within backtick (“`”) characters:
@verbatim
let $q= `select version()`;
@endverbatim
References to variables can occur in the <b>echo</b>,
<b>eval</b>, <b>exec</b>, and <b>system</b> commands. Variable
references are replaced by their values. A nonquery value assigned
to a variable in a <b>let</b> command can also refer to variables.
Variable references that occur within
\`<b><em>query</em></b>\` are expanded before the query is
sent to the server for execution.
You can refer to environment variables. For example, this command
displays the value of the <b>$PATH</b> variable from the
environment:
@verbatim
--echo $PATH
@endverbatim
<b>$mysql_errno</b> is a built-in variable that contains the
numeric error returned by the most recent SQL statement sent to the
server, or 0 if the statement executed successfully.
<b>$mysql_errno</b> has a value of −1 if no statement has yet been
sent.
<b>$mysql_errname</b> similarly contains the symbolic name of the
last error, or an empty string if there was no error.
@ref PAGE_MYSQLTEST "mysqltest" first checks @ref PAGE_MYSQLTEST
"mysqltest" variables and then environment variables. @ref
PAGE_MYSQLTEST "mysqltest" variable names are not case sensitive.
Environment variable names are case sensitive.
*/
###############################################################################
## mysqltest Flow Control Constructs
/**
@page PAGE_MYSQL_TEST_FLOW_CONTROL mysqltest Flow Control Constructs
The syntax for <b>if</b> block looks like this:
@verbatim
if (expr)
{
command list
}
@endverbatim
The syntax for <b>while</b> block looks like this:
@verbatim
while (expr)
{
command list
}
@endverbatim
An expression result is true if nonzero, false if zero. If the
expression begins with <b>!</b>, the sense of the test is reversed.
If the expression is a string that does not begin with a numeric
digit (possibly preceeded by a plus or minus sign), it evaluates as
true if non-empty. Any white space is ignored in this case, so a
string consisting of only white space is false.
There is no provision for <b>else</b> with <b>if</b>.
For a <b>while</b> loop, make sure that the loop includes some
exit condition that eventually occurs. This can be done by writing
<b><em>expr</em></b> so that it becomes false at some point.
The allowable syntax for <b><em>expr</em></b> is
<b>$<em>var_name</em></b>, <b>!$<em>var_name</em></b>,
a string or integer, or \`<b><em>query</em></b>\`.
The expression can also be a simple comparison, where the left hand
side must be a variable, and the right hand side can be any type
valid for the single expression except the negated variable. The
supported operators are ==, !=, <, <=, > and >=. Only the first two
may be used if the right hand side does not evaluate to an integer.
With ==, strings must match exactly.
If you use a string on the right hand side of the comparison, it
does not have to be quoted even if it contains spaces. It may
optionally be enclosed in single or double quotation marks which
will then be stripped off before comparison. This is in contrast to
<b>let</b> statements, where quoting is not stripped.
Examples of the expression syntax with comparisons (only the header
shown):
@verbatim
while ($counter<5) ...
if ($value == 'No such row') ...
if ($slave_count != $master_count) ...
@endverbatim
The opening <b>{</b> (curly brace) must be separated from the
preceding <b>)</b> (right parenthesis) by whitespace, such as a
space or a line break.
Variable references that occur within
\`<b><em>query</em></b>\` are expanded before the query is
sent to the server for execution.
*/
###############################################################################
## Error Handling
/**
@page PAGE_ERROR_HANDLING Error Handling
If an expected error is specified and that error occurs, @ref
PAGE_MYSQLTEST "mysqltest" continues reading input. If the command
is successful or a different error occurs, @ref PAGE_MYSQLTEST
"mysqltest" aborts.
If no expected error is specified, @ref PAGE_MYSQLTEST "mysqltest"
aborts unless the command is successful. (It is implicit that you
expect <b>$mysql_errno</b> to be 0.)
By default, @ref PAGE_MYSQLTEST "mysqltest" aborts for certain
conditions:
<ul>
<li>
A statement that fails when it should have succeeded. The
following statement should succeed if table <b>t</b> exists;
@verbatim
SELECT * FROM t;
@endverbatim
</li>
<li>
A statement that fails with an error different from that
specified:
@verbatim
--error 1
SELECT * FROM no_such_table;
@endverbatim
</li>
<li>
A statement that succeeds when an error was expected:
@verbatim
--error 1
SELECT 'a string';
@endverbatim
</li>
</ul>
You can disable the abort for errors of the first type by using the
<b>disable_abort_on_error</b> command. In this case, when errors
occur for statements that should succeed, @ref PAGE_MYSQLTEST
"mysqltest" continues processing intput.
<b>disable_abort_on_error</b> does <b>not</b> cause @ref
PAGE_MYSQLTEST "mysqltest" to ignore errors for the other two types,
where you explicitly state which error you expect. This behavior is
intentional. The rationale is that if you use the <b>error</b>
command to specify an expected error, it is assumed that the test is
sufficiently well characterized that only the specified error is
accceptable.
If you do not use the <b>error</b> command, it is assumed that you
might not know which error to expect or that it might be difficult
to characterize all possible errors that could occur. In this case,
<b>disable_abort_on_error</b> is useful for causing @ref
PAGE_MYSQLTEST mysqltest to continue processing input. This can be
helpful in the following circumstances:
<ul>
<li>
During test case development, it is useful to process all input
even if errors occur so that you can see all errors at once, such
as those that occur due to typographical or syntax errors.
Otherwise, you can see and fix only one scripting problem at a
time.
</li>
<li>
Within a file that is included with a <b>source</b> command by
several different test cases, errors might vary depending on the
processing environment that is set up prior to the <b>source</b>
command.
</li>
<li>
Tests that follow a given statement that can fail are independent
of that statement and do not depend on its result.
</li>
</ul>
*/
###############################################################################
## Creating and Executing Unit Tests
/**
@page PAGE_UNIT_TESTS Creating and Executing Unit Tests
<h3>Table of Contents</h3>
- @subpage PAGE_UNIT_TESTS_TAP
- @subpage PAGE_UNIT_TESTS_GOOGLE
- @subpage PAGE_UNIT_TESTS_MAIN_TEST_RUNS
Storage engines and plugins can have unit tests to test their
components. The top-level <b>Makefile</b> target
<b>test-unit</b> runs all unit tests: It scans the storage engine
and plugin directories, recursively, and executes all executable
files having a name that ends with <b>-t</b>.
The following sections describe MySQL unit testing using TAP and
the Google Test framework.
*/
###############################################################################
## Unit Testing Using TAP
/**
@page PAGE_UNIT_TESTS_TAP Unit Testing Using TAP
The unit-testing facility based on the Test Anything Protocol (TAP)
is mainly used when developing Perl and PHP modules. To write unit
tests for C/C++ code, MySQL has developed a library for generating
TAP output from C/C++ files. Each unit test is written as a separate
source file that is compiled to produce an executable. For the unit
test to be recognized as a unit test, the executable file has to be
of the format <b>mytext-t</b>. For example, you can create a
source file named <b>mytest-t.c</b> that compiles to produce an
executable <b>mytest-t</b>. The executable will be found and run
when you execute <b>make test</b> or <b>make test-unit</b> in the
distribution top-level directory.
Example unit tests can be found in the <b>unittest/examples</b>
directory of a MySQL source distribution. The code for the MyTAP
protocol is located in the <b>unittest/mytap</b> directory.
Each unit test file should be stored in a storage engine or plugin
directory (<b>storage/<em>engine_name</em></b> or
<b>plugin/<em>plugin_name</em></b>), or one of its
subdirectories. A reasonable convention is to create a
<b>unittest</b> subdirectory under the storage engine or plugin
directory and create unit test files in <b>unittest</b>.
*/
###############################################################################
## Unit Testing Using the Google Test Framework
/**
@page PAGE_UNIT_TESTS_GOOGLE Unit Testing Using the Google Test Framework
The Google Test unit-testing framework is available in MySQL source
trees and distributions. Google Test, like MyTAP, provides a unit-
testing framework, but Google Test provides richer functionality,
such as:
- A rich set of predicates
- User-defined predicates and assertions
- Automatic test registration
- Nice error reporting when a predicate fails (with line number, expected
and actual values, and additional comments)
- Test fixtures, and setup/teardown logic
- Death tests
- Disabled tests
- Test filtering and shuffling
Google Test runs on many platforms. Some functionality is missing on
some platforms (such as death tests and parameterized tests), so
those features should not be used.
This section provides notes about using Google Test within the
context of MySQL development. For general-purpose information about
Google Test, see these resources:
- Main Google Test page: http://code.google.com/p/googletest
- Primer: http://code.google.com/p/googletest/wiki/GoogleTestPrimer
- Advanced guide:
http://code.google.com/p/googletest/wiki/GoogleTestAdvancedGuide
- Google presentation:
http://docs.google.com/present/view?id=dfsbxvm5_0f5s4pvf9
@section SECTION_INSTALL_GOOGLE_TEST Installing Google Test and Running Unit Tests
MySQL sources do not include Google Test. To install it so that you
can use it, use one of these approaches:
<ul>
<li>
<b><em>Install Google Test in individual source
trees</em></b>. Use the <b>-DENABLE_DOWNLOADS=1</b>
configuration option. This causes <b>CMake</b> to download
Google Test and install it in your source tree for you.
</li>
<li>
<b><em>Install a single instance of Google Test</em></b>.
MySQL requires Google Test 1.6 or higher.
<ul>
<li>
To install from a tarball, download
http://googlemock.googlecode.com/files/gmock-1.6.0.zip.
</li>
<li>
To download Google Test from the Subversion repository,
use <b>svn checkout http://googletest.googlecode.com/svn/trunk/
googletest-read-only</b>
</li>
<li>
If a Google Test package is available for your operating
system, you can install it using the package manager. For
example, you might be able to use <b>apt-get</b> for Debian
Linux.
</li>
</ul>
When Google Test has been installed, set the
<b>GTEST_PREFIX</b> environment variable appropriately for
your command interpreter. For example, use this command line for
<b>bash</b>:
@verbatim
GTEST_PREFIX=/path/to/your/install;
export GTEST_PREFIX
@endverbatim
</li>
</ul>
Installing Google Test in individual source trees is the recommended
method. The single-instance installation method can be used only if
all MySQL builds on a machine take place in the same environment
(same operating system, same compiler), for reasons discussed at
https://groups.google.com/group/googletestframework/browse_thread/thread/668eff1cebf5309d?pli=1.
At configuration time, <b>CMake</b> looks for <b>gtest.h</b>. The
build process compiles all Google Test-based unit tests or ignores
them, depending on whether <b>gtest.h</b> is found.
After the build has completed, to run the tests, change location
into the <b>unittest/gunit</b> directory and execute the
<b>ctest</b> command. It need not be invoked with any options, but
you can run it with the <b>`--help`</b> option to see what options
are available.
Another way to run the unit tests is with this command:
@verbatim
make test-unit
@endverbatim
For internal MySQL testing, PushBuild has been extended to install
Google Test as a separate “package”. All trees named
<b>mysql-trunk.*</b> are set up to depend on this package.
@section SECTION_WRITING_UNIT_TESTS Writing Unit Tests for Google Test
The Google Test unit test files are located in the
<b>unittest/gunit</b> directory. You can look at these files to
see how tests are written. Here are some examples:
- <tt>sql_list-t.cc</tt>: A simple test of some list classes
- <tt>mdl-t.cc</tt>: Some tests of metadata locking (MDL),
including testing of lock acquisition from multiple threads
- <tt>mdl_mytap-t.cc</tt>: The same tests as <b>mdl-t.cc</b>, but
written for MyTAP, to illustrate some features of Google Test
Most MyTAP-based tests are likely easily converted to Google Test.
However, there might be low-level tests that absolutely must be run
on every platform, and thus require MyTAP.
As currently implemented, the Google Test unit-test programs produce
TAP output rather than the “plain” alternative. This can be disabled
by using the <b>`--disable-tap-output`</b> command-line option
when running a test executable.
To see what options are available, run a test executable with the
<b>`--help`</b> option.
*/
###############################################################################
## Unit Tests Added to Main Test Runs
/**
@page PAGE_UNIT_TESTS_MAIN_TEST_RUNS Unit Tests Added to Main Test Runs
@ref PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl" will also run unit
tests at the end of full test runs, when being run from within a
build directory. It depends on the unit tests having been built and
defined in a file <b>CTestTestfile.cmake</b> in the top level build
directory. Those will normally be there after a build using
<b>CMake</b>, but will not be in a binary package.
The unit tests are run simply by executing <b>ctest</b> with no
arguments from the top level build directory. The result will be
shown as a single test at the end, named <b>unit_tests</b> which
passes if and only if all unit tests pass. A summary of the result
will be printed, including the name of any failed unit tests. The
set of unit tests will be counted as one test (either passed or
failed) in the overall test summary.
Unit tests will by default be run only if you have not specified any
specific tests or suites on the command line for @ref
PAGE_MYSQL_TEST_RUN_PL "mysql-test-run.pl". This can be overridden
by setting the environment variable <b>MTR_UNIT_TESTS</b> to 0 or 1.
This in turn can be overriden by a command line argument
<b>`--unit-tests`</b> or <b>`--nounit-tests`</b>.
If the file <b>CTestTestfile.cmake</b> and the <b>ctest</b>
command are not both available, unit tests will be silently skipped,
unless you have used the command line option <b>`--unit-tests`</b>.
*/
###############################################################################
## Plugins for Testing Plugin Services
/**
@page PAGE_PLUGINS Plugins for Testing Plugin Services
MySQL server plugins have access to server “services”, as described in
[MySQL Services for Plugins]
(https://dev.mysql.com/doc/refman/8.0/en/plugin-services.html).
MySQL distributions include plugins that demonstrate how to test
plugin service APIs:
<ul>
<li>
The <b>test_framework</b> plugin is a bare bones plugin that
shows the minimum required framework for service testing.
</li>
<li>
The <b>test_services</b> plugin demonstrates how to test the
<b>my_plugin_log_service</b> service in unthreaded context.
</li>
<li>
The <b>test_services_threaded</b> plugin is like
<b>test_services</b>, but for threaded context.
</li>
</ul>
The source code for the plugins is located in the
<b>plugin/test_services</b> directory of MySQL source
distributions. The <b>README</b> file in that directory contains
instructions for running the test cases available for the
<b>test_services</b> and <b>test_services_threaded</b> plugins.
@note
The test plugins in <b>plugin/test_services</b> are daemon plugins
(see [Daemon Plugins]
(https://dev.mysql.com/doc/refman/8.0/en/plugin-types.html#daemon-plugin-type)).
For an example of a nondaemon service-testing plugin plugin, see the
<b>test_security_context.cc</b> file in the <b>plugin/audit_null</b>
directory. This file creates an audit plugin for testing the
<b>security_context</b> service.
Use the following procedure to create a new service-testing plugin
based on one of those provided in the <b>plugin/test_services</b>
directory. Assume that you want to create a new plugin named
<b>test_myservice</b> (or <b>test_myservice_threaded</b> to test
in threaded context).
<ol>
<li>
Select a source file to use as a basis for the new plugin:
<ul>
<li>
To begin with a bare bones plugin, copy <b>test_framework.cc</b>
to <b>test_myservice.cc</b>.
</li>
<li>
To begin with a plugin that already includes code for running tests
in unthreaded context, copy <b>test_services.cc</b> to
<b>test_myservice.cc</b>.
</li>
<li>
To begin with a plugin that already includes code for running tests
in threaded context, copy <b>test_services_threaded.cc</b> to
<b>test_myservice_threaded.cc</b>.
</li>
</ul>
</li>
<li>
There is a plugin descriptor near the end of the new source file. Modify
this descriptor appropriately for your plugin. Change the <b>name</b>,
<b>author</b>, and <b>descr</b> members that indicate the plugin
name and author and provide a description. For example, if you copied
<b>test_framework.cc</b>, those members look like this:
@verbatim
"test_framework",
"Horst Hunger",
"Test framework",
@endverbatim
Change them to something like this:
@verbatim
"test_myservice",
"Your Name Here",
"Test My Service",
@endverbatim
</li>
<li>
Modify your source file appropriately for the service to be tested:
<ul>
<li>
If you copied <b>test_framework.cc</b>, your file has no
tests initially and is set up for unthreaded context. In
this case, add code to the
<b>test_services_plugin_init()</b> function. This code
should invoke the service to be tested.
</li>
<li>
If you copied <b>test_services.cc</b> or
<b>test_services_threaded.cc</b>, the file contains tests
for the <b>my_plugin_log_service</b> service in unthreaded or
threaded contexts. Replace or modify those tests with code
for your own tests.
those tests with code for your own tests.
</li>
</ul>
</li>
</ol>
Compiling your plugin creates a plugin library file, which you
should install in the directory named by the
[plugin_dir]
https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_plugin_dir)
system variable. The file base name is the same as that of the
source file. The file name suffix differs per platform (for example,
<b>.so</b> for Unix and Unix-like systems, <b>.dll</b> for
Windows).
To install or unintall your plugin at server startup, use the
[`--plugin-load`]
(https://dev.mysql.com/doc/refman/8.0/en/server-options.html#option_mysqld_plugin-load) or
[`--plugin-load-add`]
(https://dev.mysql.com/doc/refman/8.0/en/server-options.html#option_mysqld_plugin-load-add)
option. For example, you can use these lines in an option file
(adjust the file name as necessary):
@verbatim
[mysqld]
plugin-load-add=test_myservice.so
@endverbatim
To install or uninstall the plugin at runtime, use these statements
(adjust the plugin name and file name as necessary):
@verbatim
INSTALL PLUGIN test_myservice SONAME 'test_myservice.so';
UNINSTALL PLUGIN test_myservice;
@endverbatim
For addition information about plugin loading, see
[Installing and Uninstalling Plugins]
(https://dev.mysql.com/doc/refman/8.0/en/server-plugin-loading.html).
For information about creating and running test cases for your new
plugin, adapt the instructions in the <b>README</b> file in the
<b>plugin/test_services</b> directory. Test cases for the
<b>test_services</b> and <b>test_services_threaded</b> plugins
are located in <b>mysql-test/suite/test_services</b>.
*/
###############################################################################
Reference in New Issue View Git Blame Copy Permalink