docs: rename SQL File Tests to Comet SQL Tests and Scala tests to Comet Scala Tests (#4108)

Author: andygrove

.claude/skills/audit-comet-expression/SKILL.md

@@ -13,7 +13,7 @@ This audit covers:
 1. Spark implementation across versions 3.4.3, 3.5.8, and 4.0.1
 2. Comet Scala serde implementation
 3. Comet Rust / DataFusion implementation
-4. Existing test coverage (SQL file tests and Scala tests)
+4. Existing test coverage (Comet SQL Tests and Comet Scala Tests)
 5. Gap analysis and test recommendations
 
 ---
@@ -161,7 +161,7 @@ Read the Rust implementation and check:
 
 ## Step 4: Locate Existing Comet Tests
 
-### SQL file tests
+### Comet SQL Tests
 
 ```bash
 # Find SQL test files for this expression
@@ -179,13 +179,13 @@ Read every SQL test file found and list:
 - Query modes used (`query`, `spark_answer_only`, `tolerance`, `ignore`, `expect_error`)
 - Any ConfigMatrix directives
 
-### Scala tests
+### Comet Scala Tests
 
 ```bash
 grep -r "$ARGUMENTS" spark/src/test/scala/ --include="*.scala" -l
 ```
 
-Read the relevant Scala test files and list:
+Read the relevant Comet Scala Tests and list:
 
 - Input types covered
 - Edge cases exercised
@@ -201,7 +201,7 @@ Compare the Spark test coverage (Step 2) against the Comet test coverage (Step 4
 
 For each of the following dimensions, note whether it is covered in Comet tests or missing:
 
-| Dimension                                                                                              | Spark tests it | Comet SQL test | Comet Scala test | Gap? |
+| Dimension                                                                                              | Spark tests it | Comet SQL Test | Comet Scala Test | Gap? |
 | ------------------------------------------------------------------------------------------------------ | -------------- | -------------- | ---------------- | ---- |
 | Column reference argument(s)                                                                           |                |                |                  |      |
 | Literal argument(s)                                                                                    |                |                |                  |      |
@@ -256,13 +256,13 @@ After presenting the gap analysis, ask the user:
 >
 > - [list each missing test case]
 >
-> I can add them as SQL file tests in `spark/src/test/resources/sql-tests/expressions/<category>/$ARGUMENTS.sql`
-> (or as Scala tests in `CometExpressionSuite` for cases that require programmatic setup).
+> I can add them as Comet SQL Tests in `spark/src/test/resources/sql-tests/expressions/<category>/$ARGUMENTS.sql`
+> (or as Comet Scala Tests in `CometExpressionSuite` for cases that require programmatic setup).
 
-If the user says yes, implement the missing tests following the SQL file test format described in
-`docs/source/contributor-guide/sql-file-tests.md`. Prefer SQL file tests over Scala tests.
+If the user says yes, implement the missing tests following the Comet SQL Tests format described in
+`docs/source/contributor-guide/sql-file-tests.md`. Prefer Comet SQL Tests over Comet Scala Tests.
 
-### SQL file test template
+### Comet SQL Tests template
 
 ```sql
 -- Licensed to the Apache Software Foundation (ASF) under one

.claude/skills/review-comet-pr/SKILL.md

@@ -138,15 +138,15 @@ Location: `native/spark-expr/src/`
 - [ ] No panics. Use `Result` types.
 - [ ] Efficient array operations (avoid row-by-row)
 
-#### Tests - Prefer SQL File-Based Framework
+#### Tests - Prefer Comet SQL Tests
 
-**Expression tests should use the SQL file-based framework (`CometSqlFileTestSuite`) where possible.** This framework automatically runs each query through both Spark and Comet and compares results. No Scala code is needed. Only fall back to Scala tests in `CometExpressionSuite` when the SQL framework cannot express the test. Examples include complex `DataFrame` setup, programmatic data generation, or non-expression tests.
+**Expression tests should use Comet SQL Tests (`CometSqlFileTestSuite`) where possible.** This framework automatically runs each query through both Spark and Comet and compares results. No Scala code is needed. Only fall back to Comet Scala Tests in `CometExpressionSuite` when Comet SQL Tests cannot express the test. Examples include complex `DataFrame` setup, programmatic data generation, or non-expression tests.
 
-**SQL file test location:** `spark/src/test/resources/sql-tests/expressions/<category>/`
+**Comet SQL Test location:** `spark/src/test/resources/sql-tests/expressions/<category>/`
 
 Categories include: `aggregate/`, `array/`, `string/`, `math/`, `struct/`, `map/`, `datetime/`, `hash/`, etc.
 
-**SQL file structure:**
+**Comet SQL Test structure:**
 
 ```sql
 -- Create test data
@@ -181,10 +181,10 @@ query ignore(https://github.com/apache/datafusion-comet/issues/NNNN)
 SELECT known_buggy_expr(v) FROM test_table
 ```
 
-**Running SQL file tests:**
+**Running Comet SQL Tests:**
 
 ```bash
-# All SQL file tests
+# All Comet SQL Tests
 ./mvnw test -Dsuites="org.apache.comet.CometSqlFileTestSuite" -Dtest=none
 
 # Specific test file (substring match)
@@ -199,7 +199,7 @@ SELECT known_buggy_expr(v) FROM test_table
 - [ ] Both literal values and column references tested (they use different code paths)
 - [ ] For timestamp/datetime expressions, timezone handling is tested (e.g., UTC, non-UTC session timezone, timestamps with and without timezone)
 - [ ] One expression per SQL file for easier debugging
-- [ ] If using Scala tests instead, literal tests MUST disable constant folding:
+- [ ] If using Comet Scala Tests instead, literal tests MUST disable constant folding:
   ```scala
   withSQLConf(SQLConf.OPTIMIZER_EXCLUDED_RULES.key ->
       "org.apache.spark.sql.catalyst.optimizer.ConstantFolding") {
@@ -256,7 +256,7 @@ If the PR adds a new expression or operator but does not update the relevant doc
 1. **Incomplete type support**: Spark expression supports types not handled in PR
 2. **Missing edge cases**: Null, overflow, empty string, negative values
 3. **Wrong return type**: Return type must match Spark exactly
-4. **Tests in wrong framework**: Expression tests should use the SQL file-based framework (`CometSqlFileTestSuite`) rather than adding to Scala test suites like `CometExpressionSuite`. Suggest migration if the PR adds Scala tests for expressions that could use SQL files instead.
+4. **Tests in wrong framework**: Expression tests should use Comet SQL Tests (`CometSqlFileTestSuite`) rather than adding to Comet Scala Tests like `CometExpressionSuite`. Suggest migration if the PR adds Comet Scala Tests for expressions that could use Comet SQL Tests instead.
 5. **Stale native code**: PR might need `./mvnw install -pl common -DskipTests`
 6. **Missing `getSupportLevel`**: Edge cases should be marked as `Incompatible`
 

docs/source/contributor-guide/adding_a_new_expression.md

@@ -273,9 +273,9 @@ override def getUnsupportedReasons(): Seq[String] = Seq(
 
 #### Adding Spark-side Tests for the New Expression
 
-It is important to verify that the new expression is correctly recognized by the native execution engine and matches the expected Spark behavior. The preferred way to add test coverage is to write a SQL test file using the SQL file test framework. This approach is simpler than writing Scala test code and makes it easy to cover many input combinations and edge cases.
+It is important to verify that the new expression is correctly recognized by the native execution engine and matches the expected Spark behavior. The preferred way to add test coverage is to write a Comet SQL Test. This approach is simpler than writing Comet Scala Tests and makes it easy to cover many input combinations and edge cases.
 
-##### Writing a SQL test file
+##### Writing a Comet SQL Test
 
 Create a `.sql` file under the appropriate subdirectory in `spark/src/test/resources/sql-tests/expressions/` (e.g., `string/`, `math/`, `array/`). The file should create a table with test data, then run queries that exercise the expression. Here is an example for the `unhex` expression:
 
@@ -313,17 +313,17 @@ Run the test with:
 ./mvnw test -Dsuites="org.apache.comet.CometSqlFileTestSuite unhex" -Dtest=none
 ```
 
-For full documentation on the test file format — including directives like `ConfigMatrix`, query modes like `spark_answer_only` and `tolerance`, handling known bugs with `ignore(...)`, and tips for writing thorough tests — see the [SQL File Tests](sql-file-tests.md) guide.
+For full documentation on the test file format, including directives like `ConfigMatrix`, query modes like `spark_answer_only` and `tolerance`, handling known bugs with `ignore(...)`, and tips for writing thorough tests, see the [Comet SQL Tests](sql-file-tests.md) guide.
 
 ##### Tips
 
-- **Cover both column references and literals.** Comet often uses different code paths for each. The SQL file test suite automatically disables constant folding, so all-literal queries are evaluated natively.
+- **Cover both column references and literals.** Comet often uses different code paths for each. The Comet SQL Tests suite automatically disables constant folding, so all-literal queries are evaluated natively.
 - **Include edge cases** such as `NULL`, empty strings, boundary values, `NaN`, and multibyte UTF-8 characters.
 - **Keep one file per expression** to make failures easy to locate.
 
-##### Scala tests (alternative)
+##### Comet Scala Tests (alternative)
 
-For cases that require programmatic setup or custom assertions beyond what SQL files support, you can also add Scala test cases in `CometExpressionSuite` using the `checkSparkAnswerAndOperator` method:
+For cases that require programmatic setup or custom assertions beyond what SQL files support, you can also add Comet Scala Tests in `CometExpressionSuite` using the `checkSparkAnswerAndOperator` method:
 
 ```scala
 test("unhex") {
@@ -347,7 +347,7 @@ test("unhex") {
 }
 ```
 
-When writing Scala tests with literal values (e.g., `SELECT my_func('literal')`), Spark's constant folding optimizer may evaluate the expression at planning time, bypassing Comet. To prevent this, disable constant folding:
+When writing Comet Scala Tests with literal values (e.g., `SELECT my_func('literal')`), Spark's constant folding optimizer may evaluate the expression at planning time, bypassing Comet. To prevent this, disable constant folding:
 
 ```scala
 test("my_func with literals") {

docs/source/contributor-guide/development.md

@@ -281,14 +281,14 @@ size limit to 16 MB.
 First make sure to install the Rust plugin in CLion or you can use the dedicated Rust IDE: RustRover.
 After that you can open the project in CLion. The IDE should automatically detect the project structure and import as a Cargo project.
 
-### SQL file tests (recommended for expressions)
+### Comet SQL Tests (recommended for expressions)
 
-For testing expressions and operators, prefer using SQL file tests over writing Scala test
-code. SQL file tests are plain `.sql` files that are automatically discovered and executed --
+For testing expressions and operators, prefer using Comet SQL Tests over writing Comet Scala
+Tests. Comet SQL Tests are plain `.sql` files that are automatically discovered and executed:
 no Scala code to write, and no recompilation needed when tests change. This makes it easy to
 iterate quickly and to get good coverage of edge cases and argument combinations.
 
-See the [SQL File Tests](sql-file-tests) guide for the full documentation on how to write
+See the [Comet SQL Tests](sql-file-tests) guide for the full documentation on how to write
 and run these tests.
 
 ### Running Tests in IDEA
@@ -444,7 +444,7 @@ Comet's CI does not automatically discover test suites. Instead, test suites are
 in the GitHub Actions workflow files so they can be grouped by category and run as separate parallel
 jobs. This reduces overall CI time.
 
-If you add a new Scala test suite, you must add it to the `suite` matrix in **both** workflow files:
+If you add a new Comet Scala Test suite, you must add it to the `suite` matrix in **both** workflow files:
 
 - `.github/workflows/pr_build_linux.yml`
 - `.github/workflows/pr_build_macos.yml`
@@ -471,7 +471,7 @@ Choose the group that best matches the area your test covers:
 | `parquet`     | Parquet read/write and native reader tests                 |
 | `csv`         | CSV native read tests                                      |
 | `exec`        | Execution operators, joins, aggregates, plan rules, TPC-\* |
-| `expressions` | Expression evaluation, casts, and SQL file tests           |
+| `expressions` | Expression evaluation, casts, and Comet SQL Tests          |
 | `sql`         | SQL-level behavior tests                                   |
 
 **Important:** The suite lists in both workflow files must stay in sync. A separate CI check

docs/source/contributor-guide/index.md

@@ -36,9 +36,9 @@ Adding a New Expression <adding_a_new_expression>
 Supported Spark Expressions <spark_expressions_support>
 Tracing <tracing>
 Profiling <profiling>
+Comet SQL Tests <sql-file-tests.md>
 Spark SQL Tests <spark-sql-tests.md>
 Iceberg Spark Tests <iceberg-spark-tests.md>
-SQL File Tests <sql-file-tests.md>
 Bug Triage <bug_triage>
 Roadmap <roadmap.md>
 Release Process <release_process>

docs/source/contributor-guide/sql-file-tests.md

@@ -17,15 +17,15 @@ specific language governing permissions and limitations
 under the License.
 -->
 
-# SQL File Tests
+# Comet SQL Tests
 
 `CometSqlFileTestSuite` is a test suite that automatically discovers `.sql` test files and
 runs each query through both Spark and Comet, comparing results. This provides a lightweight
-way to add expression and operator test coverage without writing Scala test code.
+way to add expression and operator test coverage without writing Comet Scala Tests.
 
 ## Running the tests
 
-Run all SQL file tests:
+Run all Comet SQL Tests:
 
 ```shell
 ./mvnw test -Dsuites="org.apache.comet.CometSqlFileTestSuite" -Dtest=none