Case作成時の注意点

以下は、一般的に守られているいくつかの規範です。

1. ファイル名の命名規則：caseファイル名は.test、resultファイル名は.resultで終わる必要があります。対応するtestsuiteのtとrの下に配置することを推奨します。

2. Caseの名前は、テストの大分類と主要なテストポイントを反映している必要があります（長すぎず、テストポイントを示せればよい）。例えば、delete機能をテストする場合、caseファイル名はdelete_で始めることができます。

3. Case名には、ドット（.）やパーセント記号（%）などのワイルドカード文字を含めないでください。アンダースコア（_）は含めることができます。

4. 同一のテストポイントについては、特定のtestsuiteの下に配置することができます。基礎テストセットのtの下に配置する場合は、統一されたプレフィックスを付けることをお勧めします。

5. Caseは長くしないでください。各主要なテストポイントの基本的なテストクラスを1つのcaseファイルに収納できます。大きな機能ポイントのすべてのテストポイントを1つのファイルに入れると、他の人が読みにくくなります。また、一般的にはabort on errorモードで実行されるため、リグレッション時に最初のcaseが失敗すると、そのcaseの後に続く多数のテストポイントは実行されません。

6. Caseファイル内の各小さなテストポイントには、コメントを付けることをお勧めします。コメントの書式は、例えば###テストポイントの説明###のように統一するとよいでしょう。

7. Caseファイルの配置：基礎テストセットはmysql_test/tの下に配置します。特定の大きな機能ポイントのテストについては、個別のtest suiteを作成することができます。test suiteの配置はmysql_test/test_suiteで、suiteの名前は任意に付けることができます。suiteの次のレベルのディレクトリにもtとrが存在し、suite内のcase名はtの下のcaseと重複しない方がよいでしょう。

8. （重要）caseがdisable rebootの状態でも、複数回実行しても合格し、その後コミットできることを保証する必要があります。この点について、以下のいくつかのコツがあります。

   1. テーブル作成前、またはcaseの最初にdrop table if exists tbl_nameを使用して、case内で新しく作成されるテーブルを削除します。

      注意

      テーブル作成前にこの判断を行わないと、前のcaseの影響を受けやすくなります。caseの最後でそのテストで使用されるテーブルを削除するのではなく、テーブル作成前またはcaseの最初にこの判断を行うことを推奨します。なぜなら、場合によってはcaseの実行途中で失敗し終了してしまい、削除操作に至らずに他のcaseの実行に影響を与える可能性があるからです。特にminitest内のcaseでは、前のcaseが失敗してもマシンが再起動しない場合、テーブルは常に存在し続けます。後のcaseでテーブル作成後に削除しないと、影響を受けます。

   2. 実行順序に影響されるシステムテーブルから取得した変数（table_id、index_nameなど）を使用する場合は、以下の結合ステートメントに置き換えてください。

      • インデックス内部名のクエリ：

        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);
        

        説明

        't2'はテーブル名を表し、末尾の'2'は2番目のインデックスを表します。

      • 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. クエリ結果が自動生成され、実行順序に依存するステートメントには--disable_query_logを指定する必要があります。

   例えば、インデックスのクエリ（このようなステートメントは多いです）は、次のように書くことができます：

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

   4. Case内でのパラメータ変更、特にグローバルなパラメータの変更については、後続のcaseの実行に影響を与えないよう、caseの最後にデフォルト値に戻します。

   5. 実行順序に依存する結果ファイルについては、例えばtable_idが明示的に表示される場合、毎回同じ結果ファイルを保証するために、--replace_columnまたは--replace_regexを使用して置き換えることができます。

9. 一般的な判断：

   1. マージ後、インデックスを使用する前に、インデックスが有効かどうかを判断する必要があります。コマンドは以下のとおりです：

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

   2. 特定のインデックスが有効かどうかを判断するには、まずテーブル名からインデックス名を取得することができます。コマンドは以下のとおりです：

      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. 日次マージを実行した後、未適用のインデックスがあるかどうかを判断する必要がない場合は、日次マージが完了しているかどうかを判断する必要があります。そうでない場合、後続のDDL操作に短時間影響を与える可能性があります。

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

10. Caseが包産到戸になった後、新規に追加されたcaseには、ownerとgroupを記述する必要があります。書式は以下のとおりです：

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

    そして、mysql_test/sql_**.pyに追加し、対応するグループに含めて毎日のリグレッションテストに組み込みます。