Microsoft DocumentDB 回归测试指南

什么是回归测试

回归测试是软件开发过程中确保新代码更改不会破坏现有功能的重要环节。在Microsoft DocumentDB项目中，回归测试主要用于验证PostgreSQL扩展功能的正确性。

测试文件结构

DocumentDB的回归测试主要包含以下几个关键部分：

1. 测试SQL文件：位于pg_documentdb/src/test/regress/sql/目录下，包含各种测试用例的SQL脚本
2. 预期输出文件：位于pg_documentdb/src/test/regress/expected/目录下，包含每个测试用例的预期输出
3. 测试调度文件：pg_documentdb/src/test/regress/basic_schedule文件定义了测试的执行顺序

如何添加新测试

第一步：创建测试SQL文件

在sql目录下创建一个新的SQL文件，例如commands_delete.sql。文件内容应该包含完整的测试场景，通常以创建测试集合开始：

-- 设置测试环境
SET citus.next_collection_id TO 12345;

-- 测试用例1
CREATE COLLECTION test_delete;
-- 更多测试SQL...

第二步：更新测试调度

编辑basic_schedule文件，添加新测试的名称（不带.sql扩展名）到适当位置。

执行回归测试

运行单个测试

make check-minimal -C pg_documentdb EXTRA_TESTS=commands_delete

首次运行时会失败，因为缺少预期输出文件。系统会自动在results目录下生成实际输出文件。

验证测试输出

1. 检查results/commands_delete.out文件内容是否符合预期
2. 如果输出正确，将其复制到expected目录作为新的预期输出

运行全部测试

make check

测试开发最佳实践

1. 集合ID管理：使用SET citus.next_collection_id确保测试独立性
2. 测试隔离：每个测试应该独立运行，不依赖其他测试的状态
3. 输出稳定性：确保测试输出在不同环境下保持一致
4. 覆盖全面：测试应覆盖正常路径和异常路径

高级技巧

1. 使用validate_test_output.sh脚本自动获取下一个可用的集合ID
2. 对于复杂测试场景，考虑拆分为多个小测试
3. 在修改现有功能时，先运行相关测试确保不会引入回归问题

通过遵循这些指南，开发者可以有效地为DocumentDB项目贡献高质量的回归测试，确保项目的稳定性和可靠性。