create-testcases（创建测试用例）

Create CUBRID test cases for a given feature or bug fix.

Given a description of the feature/fix to test (and optionally a JIRA ticket like CBRD-XXXXX), create all three types of test cases:

1. Unit tests (Google Test, C++)
2. SQL tests (csql-based)
3. Shell tests (bash-based)

$ARGUMENTS

OOS Test Case Guidelines

When creating test cases for OOS (Out of Space) scenarios:

• Use BIT VARYING (VARBIT) data type instead of string types (VARCHAR, CHAR, etc.) for data that needs predictable on-disk size.
• Reason: CUBRID compresses strings, making actual disk usage unpredictable unless the server is stopped and compression is disabled. VARBIT data is not compressed, so its size is predictable — critical for OOS tests that need to fill storage to specific thresholds.

Step 1: Understand what to test

• If a CBRD ticket is mentioned, use /jira to fetch context first.
• Read the relevant source code to understand the feature/fix being tested.
• Identify the key behaviors, edge cases, and error conditions to cover.

Step 2: Create Unit Tests

Reference: unit_tests/oos/ in the current project directory for patterns.

Location: Create in unit_tests/<feature_name>/ under the project root.

Conventions:

• File naming: test_<feature>.cpp
• Use Google Test framework (GTest::gtest)
• Shared infrastructure goes in test_<feature>_common.hpp
• Each test file has its own main(): int main(int argc, char **argv) {::testing::InitGoogleTest(&argc, argv);::testing::AddGlobalTestEnvironment(new ServerEnv());::testing::GTEST_FLAG(break_on_failure) = true; return RUN_ALL_TESTS();}
• Link against ${EP_LIBS} cubridsa GTest::gtest with SA_MODE
• Use RAII patterns (unique_ptr with custom deleters) for page/record cleanup
• Use bridge functions to access static internals when needed
• Use ASSERT_* macros with descriptive messages
• Create a CMakeLists.txt that globs test_*.cpp and creates one executable per file

Files to create:

• unit_tests/<feature>/CMakeLists.txt
• unit_tests/<feature>/test_<feature>.cpp
• Optionally: test_<feature>_common.hpp for shared utilities

Step 3: Create SQL Tests

Reference: ~/gh/tc/cubrid-testcases/sql/ for patterns.

Location: Create under ~/gh/tc/cubrid-testcases/sql/_36_guava/ (or appropriate category).

Conventions:

• Directory structure: <test_dir>/cases/<name>.sql and <test_dir>/answers/<name>.answer
• Test naming: use JIRA ticket ID if available (e.g., cbrd_26609.sql), otherwise descriptive name
• SQL file contains: setup DDL, test DML/queries, cleanup (DROP statements)
• Use autocommit on; at the top if needed
• Answer file contains expected output with === separators between statements
• If the answer file cannot be determined ahead of time, create the .sql file and add a comment explaining the user should run it and capture the output as the .answer file

Files to create:

• ~/gh/tc/cubrid-testcases/sql/<category>/<test_name>/cases/<name>.sql
• ~/gh/tc/cubrid-testcases/sql/<category>/<test_name>/answers/<name>.answer (if deterministic)

Step 4: Create Shell Tests

Reference: ~/cubrid-testcases-private-ex/shell/ for patterns.

Location: Create under ~/cubrid-testcases-private-ex/shell/ in the appropriate category.

Conventions:

• Directory structure: <category>/<test_name>/cases/<test_name>.sh
• Test script sources $init_path/init.sh for helper functions
• Standard flow: #!/bin/bash. $init_path/init.sh init test # Setup cubrid_createdb testdb cubrid server start testdb # Test operations csql -c "SQL" testdb #... verify results... # Cleanup cubrid server stop testdb cubrid deletedb testdb finish
• Use write_ok / write_nok to record pass/fail
• Use test_exec_sql and test_exec_command helpers
• Result format: <test_name>-N: OK or <test_name>-N: NOK
• Create .result file with expected pass/fail lines

Files to create:

• ~/cubrid-testcases-private-ex/shell/<category>/<test_name>/cases/<test_name>.sh
• ~/cubrid-testcases-private-ex/shell/<category>/<test_name>/cases/<test_name>.result

Step 5: Summary

After creating all test files, present a summary table:

Ask the user if they want to adjust any of the test cases.