Author: paul
Date: 2006-05-12 22:16:34 +0200 (Fri, 12 May 2006)
New Revision: 2080
Log:
r7454@polar: paul | 2006-05-12 15:18:41 -0500
Revisions for mysqltest manual.
Modified:
trunk/
trunk/mysqltest/mysqltest.xml
trunk/mysqltest/tutorial.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:7445
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:10279
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:4886
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:7454
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:10279
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:4886
Modified: trunk/mysqltest/mysqltest.xml
===================================================================
--- trunk/mysqltest/mysqltest.xml 2006-05-12 11:11:30 UTC (rev 2079)
+++ trunk/mysqltest/mysqltest.xml 2006-05-12 20:16:34 UTC (rev 2080)
@@ -162,7 +162,7 @@
<listitem>
<para>
- The <command>mysql-test-run</command>, The
+ The <command>mysql-test-run</command>,
<command>mysql-test-run.pl</command>, and
<command>mysql-stress-test.pl</command> programs that are used
for running tests.
@@ -196,7 +196,7 @@
provides options to associate with the named test case.
<literal>mysql-test-run</literal> restarts the server with
the options given in the file if the options are different
- from those required for the previous test case.
+ from those required for the currently running server.
</para>
<para>
@@ -533,7 +533,7 @@
</indexterm>
<refmeta>
- <refentrytitle>mysqltest</refentrytitle>
+ <refentrytitle><command>mysqltest</command></refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo class="manual">MySQL Database System</refmiscinfo>
@@ -1537,7 +1537,7 @@
</indexterm>
<refmeta>
- <refentrytitle>mysql-test-run</refentrytitle>
+ <refentrytitle><command>mysql-test-run</command></refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo class="manual">MySQL Database System</refmiscinfo>
@@ -3130,7 +3130,7 @@
</indexterm>
<refmeta>
- <refentrytitle>mysql-test-run.pl</refentrytitle>
+ <refentrytitle><command>mysql-test-run.pl</command></refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo class="manual">MySQL Database System</refmiscinfo>
@@ -3235,7 +3235,7 @@
</indexterm>
<refmeta>
- <refentrytitle>mysql-stress-test.pl</refentrytitle>
+ <refentrytitle><command>mysql-stress-test.pl</command></refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo class="manual">MySQL Database System</refmiscinfo>
Modified: trunk/mysqltest/tutorial.xml
===================================================================
--- trunk/mysqltest/tutorial.xml 2006-05-12 11:11:30 UTC (rev 2079)
+++ trunk/mysqltest/tutorial.xml 2006-05-12 20:16:34 UTC (rev 2080)
@@ -15,7 +15,7 @@
</para>
<para>
- This chapter provides a tutorial on running and writing test cases
+ This chapter provides a tutorial on writing and running test cases
for the MySQL test framework. 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
@@ -30,13 +30,13 @@
<title>Running Test Cases</title>
<para>
- Normally, you run the test suite either from within a source tree
+ 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. To run tests, you should be
- located in the <filename>mysql-test</filename> directory of your
- source tree or installed distribution. In a source distribution,
- <filename>mysql-test</filename> is under the root of the source
- tree. In a binary distribution, the location of
+ distribution has been installed. To run tests, your current
+ working directory should be the <filename>mysql-test</filename>
+ directory of your source tree or installed distribution. In a
+ source distribution, <filename>mysql-test</filename> is under the
+ root of the source tree. In a binary distribution, the location of
<filename>mysql-test</filename> depends on the distribution
layout. The program that runs the test suite,
<command>mysql-test-run</command>, will figure out whether you are
@@ -60,10 +60,16 @@
</para>
<programlisting>
-shell> <userinput>./mysql-test-run --local --force</userinput>
+shell> <userinput>./mysql-test-run --force --local</userinput>
</programlisting>
<para>
+ By default, <command>mysql-test-run</command> exits if a test case
+ fails. <option>--force</option> causes execution to continue
+ regardless of test case failure.
+ </para>
+
+ <para>
The <option>--local</option> option tells
<command>mysql-test-run</command> not to use an already running
server, but to start a server itself to use for the tests. This
@@ -72,12 +78,6 @@
</para>
<para>
- By default, <command>mysql-test-run</command> exits if a test case
- fails. <option>--force</option> causes execution to continue
- regardless of test case failure.
- </para>
-
- <para>
For a full list of the supported options, see
<xref linkend="mysql-test-run"/>.
</para>
@@ -86,24 +86,21 @@
Test case files have names like
<filename>t/<replaceable>test_name</replaceable>.test</filename>,
where <replaceable>test_name</replaceable> is the name of the test
- case.
+ case. Each name should be the test case name, not the full test
+ case filename. To run one or more specific test cases, name them
+ on the <command>mysql-test-run</command> command line. (You do not
+ specify the full test case filename.) The following command runs
+ the test case named <literal>rpl_abcd</literal>, which has a test
+ file of <filename>t/rpl_abcd.test</filename>:
</para>
- <para>
- To run one or more specific test cases, give their names on the
- <command>mysql-test-run</command> command line. (You do not
- specify the full test case filename.) This command runs the test
- case in the <filename>t/rpl_abcd.test</filename> file:
- </para>
-
<programlisting>
shell> <userinput>./mysql-test-run rpl_abcd</userinput>
</programlisting>
<para>
- If you have a family of test cases for which the names share a
- common prefix, you can run all tests that have that prefix by
- using the <option>--do-tests</option> option:
+ To run a family of test cases for which the names share a common
+ prefix, use the <option>--do-tests</option> option:
</para>
<programlisting>
@@ -111,7 +108,9 @@
</programlisting>
<para>
- For example, the following command runs the replication tests:
+ For example, the following command runs the replication tests
+ (test cases that have names beginning with
+ <literal>rpl</literal>):
</para>
<programlisting>
@@ -119,20 +118,22 @@
</programlisting>
<para>
- <command>mysql-test-run</command> sets up the environment for
- calling the <command>mysqltest</command> program and starting a
- server, and so forth. <command>mysqltest</command> handles
- operations such as reading input from the test case file, starting
- managers, creating server connections, and sending SQL statements
- to servers.
+ <command>mysql-test-run</command> starts the MySQL server if
+ necessary, sets up the environment for calling the
+ <command>mysqltest</command> program, and invokes
+ <command>mysqltest</command> to run the test case. For each test
+ case to be run, <command>mysqltest</command> handles operations
+ such as reading input from the test case file, starting managers,
+ creating server connections, and sending SQL statements to
+ servers.
</para>
<para>
- The test case language is a mix of commands that the
+ The language used in test case files is a mix of commands that the
<command>mysqltest</command> program understands and SQL
statements. Input that <command>mysqltest</command> doesn't
- understand is assumed to be SQL statements to be sent to the
- database server. This makes the test case language familiar to
+ 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.
</para>
@@ -143,8 +144,7 @@
the server or servers needed on ports that do not conflict with
ports used a production server, if you happen to have one on the
same machine. (The test run uses ports in the range around 9300,
- so production servers should not use ports in that range.) [Q:
- Doesn't the preceding paragraph assume that if you have a
+ so production servers should not use ports in that range.)
</para>
<section id="tutorial-simultaneous-test-runs">
@@ -153,21 +153,21 @@
<para>
If you have multiple users that run tests simultaneously on the
- same machine, you must specify the ports to the
- <command>mysql-test-run</command> program, so that no test run
- conflicts with others running concurrently. You add unique port
- arguments to <command>mysql-test-run</command>, such as
- <option>--no-manager --master_port=3911
+ same machine, you must specify to the
+ <command>mysql-test-run</command> program which ports to user so
+ that no test run conflicts with others running concurrently. You
+ add unique port arguments to <command>mysql-test-run</command>,
+ such as <option>--no-manager --master_port=3911
--slave_port=3927</option>.
</para>
<para>
- Also note that only one person can run the
- <command>mysql-test-run</command> program in the same
- <filename>mysql-test</filename> directory on a shared drive, at
- the same time. The <filename>mysql-test/var</filename> directory
- created and used by <command>mysql-test-run</command> cannot be
- shared between simultaneous test runs. A test run can use the
+ Only one person can run the <command>mysql-test-run</command>
+ program in the same <filename>mysql-test</filename> directory on
+ a shared drive, at the same time. The
+ <filename>mysql-test/var</filename> directory created and used
+ by <command>mysql-test-run</command> cannot be shared between
+ simultaneous test runs. A test run can use the
<option>--var=<replaceable>dir_path</replaceable></option>
option to specify an alternate directory not used by other runs.
</para>
@@ -181,48 +181,54 @@
<title>Writing a Test Case: Quick Start</title>
<para>
- The basic principle is that evaluation of the output resulting
- from running a test case is based on comparison of that output
- with the expected result. This is just a <command>diff</command>
- 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 expected
- variation.
+ 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 <command>diff</command> 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 expected variation.
</para>
<para>
- Use the following procedure to write a new test case:
+ Use the following procedure to write a new test case.
+ <replaceable>test_name</replaceable> represents the name of the
+ test case.
</para>
<para>
- [Q: This procedure seems to ignore the existence of the
- <option>--record</option> option. Perhaps it was written before
- that option was available? In any case, is this the procedure that
- people actually use, or should it be rewritten to use
- <option>--record</option>?]
+ It's 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.
</para>
<orderedlist>
<listitem>
<para>
- Change directories to the test directory
+ Change location to the test directory
<filename>mysql-<replaceable>version</replaceable>/mysql-test</filename>:
</para>
<programlisting>
shell> <userinput>cd mysql-<replaceable>version</replaceable>/mysql-test</userinput>
</programlisting>
+
+ <para>
+ <filename>mysql-<replaceable>version</replaceable></filename>
+ represents the root directory of your source tree, such as
+ <filename>mysql-5.0</filename> or
+ <filename>mysql-5.1</filename>.
+ </para>
</listitem>
<listitem>
<para>
- Create the test in a file
+ Create the test case in a file
<filename>t/<replaceable>test_name</replaceable>.test</filename>.
- You can do this with any test editor. For details of the
+ You can do this with any text editor. For details of the
language used for writing <command>mysqltest</command> test
cases, see <xref linkend="mysqltest-reference"/>.
</para>
@@ -250,7 +256,10 @@
<listitem>
<para>
- The failing test will create a file
+ 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
<filename>r/<replaceable>test_name</replaceable>.reject</filename>.
Examine this file. If it looks okay, copy its content to the
result file:
@@ -259,6 +268,17 @@
<programlisting>
shell> <userinput>cp r/<replaceable>test_name</replaceable>.reject r/<replaceable>test_name</replaceable>.result</userinput>
</programlisting>
+
+ <para>
+ Another way to create the result file is by invoking
+ <command>mysql-test-run</command> with the
+ <option>--record</option> option to record the test output in
+ the result file:
+ </para>
+
+<programlisting>
+[SHOW, VERIFY]
+</programlisting>
</listitem>
<listitem>
@@ -283,10 +303,10 @@
</orderedlist>
<para>
- The environment can also be set up so that the
- <command>mysqltest</command> program can be called directly. For
- more information about the <command>mysqltest</command> program,
- see <xref linkend="mysqltest"/>.
+ The environment can also be set up so that you can invoke the
+ <command>mysqltest</command> program directly. For more
+ information about the <command>mysqltest</command> program, see
+ <xref linkend="mysqltest"/>.
</para>
</section>
@@ -296,7 +316,12 @@
<title>Writing a Test Case</title>
<para>
- You write test cases with any text editor that uses linefeed
+ [Q: Aren't there any test case files with non-ASCII content? For
+ example, character set tests?]
+ </para>
+
+ <para>
+ You write test case files with any text editor that uses linefeed
(newline) as the end-of-line character. Filenames should be
lowercase ASCII with no spaces.
</para>
@@ -317,12 +342,12 @@
</para>
<para>
- One test file can be a collection of individual tests that belong
- together. If one of the tests fails, the entire test case fails.
- Although this makes it 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 files not too big, not too
- small.
+ 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 this makes it 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.
</para>
<para>
@@ -359,16 +384,16 @@
<para>
Each test case (that is, each test file) must be self contained
- and independent of other test cases. This means that you are not
- allowed to 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 <filename>mysq-test/include</filename>
- directory, and then put a <literal>source</literal> 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
+ 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
+ <filename>mysq-test/include</filename> directory, and then put a
+ <literal>source</literal> 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
<filename>mysql-test/include/create_my_table.inc</filename>. Then
put this command in each test case file that needs the
initialization code:
@@ -402,8 +427,9 @@
</para>
<para>
- <xref linkend="mysqltest-input-conventions"/>, discusses in detail
- the input syntax for <command>mysqltest</command> test cases.
+ <xref linkend="mysqltest-input-conventions"/>, discusses the
+ details of input syntax for <command>mysqltest</command> test
+ cases.
</para>
<section id="tutorial-sample-test-case">
@@ -427,21 +453,23 @@
<para>
The first rows try to clean up from possible earlier runs of the
- test case by dropping the <literal>t1</literal> table. We
- disable storing warnings (<literal>disable_warnings</literal>)
- in the output during this because we are not interested to know
- whether the table <literal>t1</literal> was there or not. Then
- we enable storing warnings again
- (<literal>enable_warnings</literal>) and enable verbose warnings
- in MySQL using the <literal>SET SQL_WARNINGS=1;</literal>
- statement.
+ test case by dropping the <literal>t1</literal> table. The test
+ cases uses <literal>disable_warnings</literal> to prevent
+ warnings from being written to the output. It is not of any
+ interest at this point during the test to know whether the table
+ <literal>t1</literal> was there. After dropping the table, the
+ test case uses <literal>enable_warnings</literal> so that
+ subsequent warnings will be written to the output. The test case
+ also enables verbose warnings in MySQL using the <literal>SET
+ SQL_WARNINGS=1;</literal> statement.
</para>
<para>
- We create the table <literal>t1</literal> and try some
- operations. The creation of the table and first insertion will
- not create any warnings, but the last line will. The output that
- results from running the test looks like this:
+ Next, the test case creates the table <literal>t1</literal> and
+ tries some operations. The creation of the table and first
+ insertion will not create any warnings, but the second insertion
+ will. The output that results from running the test looks like
+ this:
</para>
<programlisting>
@@ -471,9 +499,9 @@
</section>
- <section id="tutorial-naming-rules">
+ <section id="tutorial-naming-conventions">
- <title>Naming Rules for Database Objects</title>
+ <title>Naming Conventions for Database Objects</title>
<para>
It is possible to run test cases against a production server.
@@ -483,11 +511,24 @@
them using names like this:
</para>
-<programlisting>
-table names : t1, t2, t3.....
-view names : v1, v2, v3.....
-</programlisting>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Table names: <literal>t1</literal>, <literal>t2</literal>,
+ <literal>t3</literal>, ...
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ View names: <literal>v1</literal>, <literal>v2</literal>,
+ <literal>v3</literal>, ...
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
<para>
Look in the existing test cases for examples of how to name
objects. Of course, you can name columns and other objects
@@ -510,7 +551,7 @@
For efficiency, the <command>mysqltest</command> test engine
does not start with a clean new database for running each test
case, so a test case generally starts with a <quote>cleaning up
- section.</quote> Assume that our test case will use two tables
+ section.</quote> Assume that a test case will use two tables
named <literal>t1</literal> and <literal>t2</literal>. The test
case should begin by making sure that any old tables with those
names do not exist:
@@ -544,26 +585,22 @@
So let's put in some SQL code into this test case:
</para>
- <para>
- [Q: There is a disconnect between this test case content and the
- preceding cleanup code? (The cleanup code removes
- <literal>t1</literal> and <literal>t2</literal>, but the test
- never uses <literal>t2</literal>.)]
- </para>
-
<programlisting>
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;
+drop table t1, t2;
</programlisting>
</section>
@@ -609,7 +646,7 @@
<para>
Running the test as shown creates a result file named
- <filename>mysql-test/r/foo.result</filename>. The file has this
+ <filename>mysql-test/r/foo.result</filename> that has this
content:
</para>
@@ -619,17 +656,23 @@
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
+Period Varor_period
+9410 9412
select t1.* from t1;
-Period Varor_period
-9410 9412
-drop table t1;
+Period Varor_period
+9410 9412
+select * from t1 inner join t2 using (Period);
+Period Varor_period
+9410 9412
+drop table t1, t2;
+ok
</programlisting>
<para>
@@ -676,17 +719,19 @@
--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));
</programlisting>
@@ -703,8 +748,8 @@
</para>
<programlisting>
-At line 19: query 'create table t1 (something smallint(4))'
- failed: 1050: Table 't1' already exists
+At line 21: query 'create table t1 (something smallint(4))'
+failed: 1050: Table 't1' already exists
</programlisting>
<para>
@@ -782,7 +827,8 @@
<para>
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 case case file preceding those statements:
+ following line to the test case file preceding the first
+ table-creation statement:
</para>
<programlisting>
@@ -803,27 +849,37 @@
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
+Period Varor_period
+9410 9412
affected rows: 1
select t1.* from t1;
-Period Varor_period
-9410 9412
+Period Varor_period
+9410 9412
affected rows: 1
-drop table t1;
+select * from t1 inner join t2 using (Period);
+Period Varor_period
+9410 9412
+affected rows: 1
+drop table t1, t2;
affected rows: 0
+ok
</programlisting>
<para>
To turn off the affected-rows reporting, add this command to the
- test file:
+ test case file:
</para>
<programlisting>
@@ -833,13 +889,12 @@
<para>
Options can in general 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 can then enable the
- display of query metadata using
- <literal>enable_metadata</literal>. 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.
+ internals of the database as well. We could enable the display
+ of query metadata using <literal>enable_metadata</literal>. 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.
</para>
<para>
@@ -859,8 +914,8 @@
and enable recording again with
<literal>enable_query_log</literal>. You can disable the
recording of the output from executing commands using
- <literal>disable_result_log</literal> and enable again with
- <literal>enable_result_log</literal>.
+ <literal>disable_result_log</literal> and enable recording again
+ with <literal>enable_result_log</literal>.
</para>
</section>
@@ -924,39 +979,42 @@
-------------------------------------------------------
*** r/foo.result Thu Jan 20 18:38:37 2005
--- r/foo.reject Thu Jan 20 18:39:00 2005
-***************
-*** 11,25 ****
+*** 16,32 ****
select period from t1;
period
9410
-! 0037
+! 0034
affected rows: 2
select * from t1;
- Period Varor_period
- 9410 9412
-! 0037 9999
+ Period Varor_period
+ 9410 9412
+! 0034 9999
affected rows: 2
select t1.* from t1;
- Period Varor_period
- 9410 9412
-! 0037 9999
+ Period Varor_period
+ 9410 9412
+! 0034 9999
affected rows: 2
---- 11,25 ----
+ select * from t1 inner join t2 using (Period);
+ Period Varor_period
+--- 16,32 ----
select period from t1;
period
9410
-! 0059
+! 0038
affected rows: 2
select * from t1;
- Period Varor_period
- 9410 9412
-! 0059 9999
+ Period Varor_period
+ 9410 9412
+! 0038 9999
affected rows: 2
select t1.* from t1;
- Period Varor_period
- 9410 9412
-! 0059 9999
+ Period Varor_period
+ 9410 9412
+! 0038 9999
affected rows: 2
+ select * from t1 inner join t2 using (Period);
+ Period Varor_period
-------------------------------------------------------
</programlisting>
@@ -991,32 +1049,60 @@
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
+Period Varor_period
+SECONDS 9412
+SECONDS 9999
affected rows: 2
select t1.* from t1;
-Period Varor_period
-SECONDS 9412
-SECONDS 9999
+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
</programlisting>
+ <para>
+ If a file exists named
+ <filename>t/<replaceable>test_name</replaceable>-master.opt</filename>,
+ <command>mysql-test-run</command> examines it for extra options
+ that the server needs to be run with when executing the
+ <replaceable>test_name</replaceable> test case. If no server has
+ yet been started or the current server is running with different
+ options, <command>mysql-test-run</command> restarts the server
+ with the new options.
+ </para>
+
+ <para>
+ [TODO: Also need to describe what other option files might be
+ used (e.g., -slave.pt).
+ </para>
+
</section>
<section id="tutorial-server-options">
- <title>Setting Server Options</title>
+ <title>Specifying Test Case-Specific Server Options</title>
<para>
Many server options can be set from within test cases by using
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r2080 - in trunk: . mysqltest | paul | 12 May |
