Test case writing conventions

Observe the following conventions for writing test cases:

1. Naming: The test file name must end with .test, and the result file name must end with .result. We recommend that you respectively place the two files in the t and r folders of the corresponding test suite.

2. The name of a test case must reflect the test category and the main test point, but it must not be too long. For example, for a test case that tests the delete feature, the test case name can begin with delete_.

3. A test case name must not contain wildcard characters such as periods (.) and percent signs (%), but it can contain underscores (_).

4. You can place the same type of test cases in a specific test suite. If you want to place them in the basic test suite t, we recommend that you add a unified prefix to them.

5. A test case must not be too long. You can place the basic test points of a large test category in the same test case. However, a test case that contains all test points of a large test category is not friendly to readers. In addition, test cases are run in an abort-on-error manner. If a test case fails at the beginning during regressive testing, a large number of test points in the test case will not be run.

6. We recommend that you add a comment to each test point in a test file in a unified manner, such as ###Test point description###.

7. Storage location: Place the test files of a basic test suite in mysql_test/t. You can create a separate test suite for a large test category, place the test suite in mysql_test/test_suite, and name the test suite as needed. The lower-level directory of the test suite also contains the t and r folders. The test case names in a test suite must not be duplicated with those in the t folder.

8. (Important) Submit a test case only after it is executed several times when server reboot is disabled. Note the following points:

   1. Before table creation or at the beginning of a test case, use the drop table if exists tbl_name command to drop the table that is about to be created in the test case.

      Notice

      If you skip this step before table creation, the test result may be affected by previous test cases. We recommend that you perform this step before table creation or at the beginning of the test case, rather than dropping the table used in the test case at the end of the test case. Because if a test case fails, mysqltest will exit and the table used in the test case is not dropped. If the server is not rebooted after a test case fails, the table created in the test case always exists and will affect the running of subsequent test cases, especially those in a minitest.

   2. For system table variables that are affected by the execution sequence, such as table_id and index_name, replace them with the following statements when you want to use them.

      • Query the internal name of an index:

        let $idx22 = query_get_value(select a.table_name from oceanbase.__all_table as a inner join (select * from oceanbase.__all_table where table_name='t2') b on a.data_table_id=b.table_id order by a.table_name, table_name, 2);
        

        Note

        Here, t2 indicates the table name, and 2 at the end indicates the second index.

      • Query table_id:

        let $table_id=query_get_value(select table_id from oceanbase.__all_table where table_name='gv$election_info',table_id,1);
        

   3. For a query statement that automatically generates the results and that depends on the execution sequence, specify the --disable_query_log option.

      For example, execute the following statements to query indexes:

      --disable_query_log
      eval select * from $idx1;
      eval select * from $idx2;
      --enable_query_log
      

   4. For parameters modified during the running of a test case, especially global parameters, restore these parameters to their default values at the end of the test case to avoid affecting the running of subsequent test cases.

   5. If the result file depends on the execution sequence, replace table_id with --replace_column or --replace_regex to ensure that the result file is the same each time when the test case is executed.

9. Here are some general verification commands:

   1. After a major compaction, you must run the following command to verify whether the indexes are valid before you use them:

      alter system major freeze;
      --source mysql_test/include/check_all_idx_ok.inc
      

   2. To verify whether a specific index is valid, run the following command to search for the index name based on the table name:

      let $idx1 = query_get_value(select a.table_name from __all_table as a inner join (select * from __all_table where table_name='t1') b on a.data_table_id=b.table_id, table_name, 1);
      let $index_name = __idx_3003_i2;
      --source mysql_test/include/check_idx_status.inc
      

   3. After a major compaction, if you do not need to verify whether any index is invalid, you must verify whether the major compaction is completed. Otherwise, subsequent DDL operations will be affected for a short time.

      alter system major freeze;
      --source mysql_test/include/wait_daily_merge.inc
      

10. After the test cases are assigned to specific test engineers, you must specify the owner and group for new test cases in the following format:

    owner:*
    owner *
    description: this case is used for
    

    Add mysql_test/sql_**.py to the corresponding group for daily regressive testing.