Documentation Home
The MySQL Test Framework, Version 1.0
Download this Manual
PDF (US Ltr) - 443.8Kb
PDF (A4) - 445.5Kb
EPUB - 101.9Kb

The MySQL Test Framework, Version 1.0  /  Writing Test Cases  /  Other Tips for Writing Test Cases

4.15 Other Tips for Writing Test Cases

  • Writing loops

    If you need to do something in a loop, you can use something like this:

    let $1= 1000;
    while ($1)
     # execute your statements here
     dec $1;
  • Pausing between statements

    To sleep between statements, use the sleep command. It supports fractions of a second. For example, sleep 1.3; sleeps 1.3 seconds.

    Try not to use sleep or real_sleep 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.

  • 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 echo command for this:

    --echo # Comment to explain the following output
  • Sorting result sets

    If a test case depends on SELECT output being in a particular row order, use an ORDER BY 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.

  • Performing file system operations

    Avoid using exec or system 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. mysqltest now has several commands to perform these operations portably, so these commands should be used instead: remove_file, chmod, mkdir, and so forth.

  • 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.

Download this Manual
PDF (US Ltr) - 443.8Kb
PDF (A4) - 445.5Kb
EPUB - 101.9Kb