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` に追加し、対応するグループに組み込んで、毎日のリグレッションに含めます。