summaryrefslogtreecommitdiff
path: root/mysql-test/README
diff options
context:
space:
mode:
Diffstat (limited to 'mysql-test/README')
-rw-r--r--mysql-test/README101
1 files changed, 60 insertions, 41 deletions
diff --git a/mysql-test/README b/mysql-test/README
index 28b8203b2dc..d925964fed5 100644
--- a/mysql-test/README
+++ b/mysql-test/README
@@ -1,74 +1,93 @@
-This directory contains a test suite for the MySQL daemon. To run
-the currently existing test cases, simply execute ./mysql-test-run in
-this directory. It will fire up the newly built mysqld and test it.
+This directory contains test suites for the MariaDB server. To run
+currently existing test cases, execute ./mysql-test-run in this directory.
-Note that you do not have to have to do "make install", and you could
-actually have a co-existing MySQL installation. The tests will not
-conflict with it. To run the test suite in a source directory, you
-must do make first.
+Some tests are known to fail on some platforms or be otherwise unreliable.
+The file "unstable-tests" contains the list of such tests along with
+a comment for every test.
+To exclude them from the test run, execute
+ # ./mysql-test-run --skip-test-list=unstable-tests
-All tests must pass. If one or more of them fail on your system, please
-read the following manual section for instructions on how to report the
-problem:
+In general you do not have to have to do "make install", and you can have
+a co-existing MariaDB installation, the tests will not conflict with it.
+To run the tests in a source directory, you must do "make" first.
+
+In Red Hat distributions, you should run the script as user "mysql".
+The user is created with nologin shell, so the best bet is something like
+ # su -
+ # cd /usr/share/mysql-test
+ # su -s /bin/bash mysql -c "./mysql-test-run --skip-test-list=unstable-tests"
+
+This will use the installed MariaDB executables, but will run a private
+copy of the server process (using data files within /usr/share/mysql-test),
+so you need not start the mysqld service beforehand.
+
+You can omit --skip-test-list option if you want to check whether
+the listed failures occur for you.
+
+To clean up afterwards, remove the created "var" subdirectory, e.g.
+ # su -s /bin/bash - mysql -c "rm -rf /usr/share/mysql-test/var"
+
+If one or more tests fail on your system on reasons other than listed
+in lists of unstable tests, please read the following manual section
+for instructions on how to report the problem:
https://mariadb.com/kb/en/reporting-bugs
If you want to use an already running MySQL server for specific tests,
use the --extern option to mysql-test-run. Please note that in this mode,
-the test suite expects you to provide the names of the tests to run.
+you are expected to provide names of the tests to run.
+
For example, here is the command to run the "alias" and "analyze" tests
with an external server:
-mysql-test-run --extern socket=/tmp/mysql.sock alias analyze
+ # mysql-test-run --extern socket=/tmp/mysql.sock alias analyze
-To match your setup, you might also need to provide --socket, --user, and
-other relevant options.
+To match your setup, you might need to provide other relevant options.
-With no test cases named on the command line, mysql-test-run falls back
-to the normal "non-extern" behavior. The reason for this is that some
-tests cannot run with an external server.
+With no test names on the command line, mysql-test-run will attempt
+to execute the default set of tests, which will certainly fail, because
+many tests cannot run with an external server (they need to control the
+options with which the server is started, restart the server during
+execution, etc.)
You can create your own test cases. To create a test case, create a new
file in the t subdirectory using a text editor. The file should have a .test
extension. For example:
- xemacs t/test_case_name.test
+ # xemacs t/test_case_name.test
- In the file, put a set of SQL statements that create some tables,
- load test data, and run some queries to manipulate it.
+In the file, put a set of SQL statements that create some tables,
+load test data, and run some queries to manipulate it.
- We would appreciate it if you name your test tables t1, t2, t3 ... (to not
- conflict too much with existing tables).
+Your test should begin by dropping the tables you are going to create and
+end by dropping them again. This ensures that you can run the test over
+and over again.
- Your test should begin by dropping the tables you are going to create and
- end by dropping them again. This ensures that you can run the test over
- and over again.
-
- If you are using mysqltest commands (like result file names) in your
- test case, you should create the result file as follows:
+If you are using mysqltest commands in your test case, you should create
+the result file as follows:
- mysql-test-run --record test_case_name
+ # mysql-test-run --record test_case_name
- or
+ or
- mysqltest --record < t/test_case_name.test
+ # mysqltest --record < t/test_case_name.test
- If you only have a simple test cases consisting of SQL statements and
- comments, you can create the test case in one of the following ways:
+If you only have a simple test case consisting of SQL statements and
+comments, you can create the result file in one of the following ways:
- mysql-test-run --record test_case_name
+ # mysql-test-run --record test_case_name
- mysql test < t/test_case_name.test > r/test_case_name.result
+ # mysql test < t/test_case_name.test > r/test_case_name.result
- mysqltest --record --database test --result-file=r/test_case_name.result < t/test_case_name.test
+ # mysqltest --record --database test --result-file=r/test_case_name.result < t/test_case_name.test
- When this is done, take a look at r/test_case_name.result
- - If the result is incorrect, you have found a bug. In this case, you should
- edit the test result to the correct results so that we can verify
- that the bug is corrected in future releases.
+When this is done, take a look at r/test_case_name.result .
+If the result is incorrect, you have found a bug. In this case, you should
+edit the test result to the correct results so that we can verify that
+the bug is corrected in future releases.
If you want to submit your test case you can send it
-to maria-developers@lists.launchpad.com or attach it to a bug report on
+to maria-developers@lists.launchpad.net or attach it to a bug report on
http://mariadb.org/jira/.
If the test case is really big or if it contains 'not public' data,