- 4.2 Test Case Coding Guidelines
- 4.2.1 File Naming and Organization Guidelines
- 4.2.2 Test Case Content-Formatting Guidelines
- 4.2.3 Naming Conventions for Database Objects
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: Coding Guidelines
Other guidelines may be found in this page, which discusses general principles of test-case writing: How to Create Good Tests
The following guidelines are particularly applicable to writing test cases:
To write a test case file, use any text editor that uses linefeed (newline) as the end-of-line character.
Avoid lines longer than 80 characters unless there is no other choice.
-
A comment in a test case is started with the “
#” character.Note
The older “
--” syntax for writing comments is deprecated because of the potential for accidentally writing comments that begin with a keyword and being executed. This syntax cannot be used for comments as of MySQL 5.1.30.Section 6.1, “mysqltest Input Conventions”, discusses the details of input syntax for mysqltest test cases.
Use spaces, not tabs.
-
Write SQL statements using the same style as our manual:
Use uppercase for SQL keywords.
Use lowercase for identifiers (names of objects such as databases, tables, columns, and so forth).
Ignore this guidline if your intent is to test lettercase processing for SQL statements, of course.
Use lowercase for mysqltest commands (
echo,sleep,let, 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, please use the guideline for new tests. Lettercase for older tests can be left as is, unless perhaps you need to revise them significantly.
Break a long SQL statement into multiple lines to make it more readable. This means that you will need to write it using a “
;” delimiter at the end of the statement rather than using “--” at the beginning because the latter style works only for single-line statements.-
Include comments. They save the time of others. In particular:
Please include a header in test files that indicates the purpose of the test and references the corresponding worklog task, if any.
Comments for a test that is related to a bug report should include the bug number and title.
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.
Example SQL statement, formatted onto multiple lines for readability:
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 ... ;
Example test file header:
########### 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 # # # ########################################################################
Example test reference to bug report:
# Bug#3671 Stored procedure crash if function has "set @variable=param"
