- 4 Writing Test Cases
- 4.1 Writing a Test Case: Quick Start
- 4.2 Test Case Coding Guidelines
- 4.3 Sample Test Case
- 4.4 Cleaning Up from a Previous Test Run
- 4.5 Generating a Test Case Result File
- 4.6 Checking for Expected Errors
- 4.7 Controlling the Information Produced by a Test Case
- 4.8 Dealing with Output That Varies Per Test Run
- 4.9 Passing Options from mysql-test-run.pl to mysqld or mysqltest
- 4.10 Specifying Test Case-Specific Server Options
- 4.11 Using Include Files to Simplify Test Cases
- 4.12 Controlling the Binary Log Format Used for Tests
- 4.13 Writing Replication Tests
- 4.14 Thread Synchronization in Test Cases
- 4.15 Other Tips for Writing Test Cases
[+/-]
Before MySQL 5.1, the server does all binary logging using statement-based logging (SBL), which logs events as statements that produce data changes. As of MySQL 5.1, the server also supports 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 binlog_format system
variable indicates which log format is in effect. It has possible
values of STATEMENT, ROW,
and MIXED (not case sensitive). This system
variable can be set at server startup by specifying
--binlog_format=
on the command line or in an option file. A user who has the
valueSUPER privilege can change the log format at
runtime. For example:
SET GLOBAL binlog_format = STATEMENT;
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 mysql-test-run.pl that tell it which format mysqld 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.
