Case作成時の注意点

以下は慣例となっているいくつかの規範です：

1. 命名に関して：caseファイル名は.test、resultファイルは.resultで終わらせる必要があります。それぞれのtestsuiteのtとrの下に配置することを推奨します。

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

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

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

5. Caseは長くしないでください。各主要なテストポイントの基本的なテストクラスを1つのcaseファイルに配置するだけで十分です。もし1つの大きな機能ポイントのすべてのテストポイントを1つのファイルにまとめると、他者が読みにくくなります。また、一般的にはabort on errorモードで実行されるため、リグレッション時に最初の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を使用する必要があります。

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

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

   4. Case内での構成パラメータの変更、特にglobalの構成パラメータについては、後続の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に追加し、対応するグループに組み込んで毎日のリグレッションに含めます。