Back to Details

creating-oracle-to-postgres-migration-integration-tests

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Creating Integration Tests for Oracle-to-PostgreSQL Migration

为Oracle到PostgreSQL迁移创建集成测试

Generates integration test cases for data access artifacts in a single target project. Tests validate behavior consistency when running against Oracle or PostgreSQL.
为单个目标项目中的数据访问构件生成集成测试用例。这些测试用于验证在Oracle或PostgreSQL上运行时的行为一致性。

Prerequisites

前提条件

  • The test project must already exist and compile (scaffolded separately).
  • Read the existing base test class and seed manager conventions before writing tests.
  • 测试项目必须已存在且可编译（需单独搭建）。
  • 在编写测试前，需阅读现有的基础测试类和种子管理器约定。

Workflow

工作流程

Test Creation:
- [ ] Step 1: Discover the test project conventions
- [ ] Step 2: Identify testable data access artifacts
- [ ] Step 3: Create seed data
- [ ] Step 4: Write test cases
- [ ] Step 5: Review determinism
Step 1: Discover the test project conventions
Read the base test class, seed manager, and project file to understand inheritance patterns, transaction management, and seed file conventions.
Step 2: Identify testable data access artifacts
Scope to the target project only. List data access methods that interact with the database — repositories, DAOs, stored procedure callers, query builders.
Step 3: Create seed data
  • Follow seed file location and naming conventions from the existing project.
  • Reuse existing seed files when possible.
  • Avoid 
    TRUNCATE TABLE
    — keep existing database data intact.
  • Do not commit seed data; tests run in transactions that roll back.
  • Ensure seed data does not conflict with other tests.
  • Load and verify seed data before assertions depend on it.
Step 4: Write test cases
  • Inherit from the base test class to get automatic transaction create/rollback.
  • Assert logical outputs (rows, columns, counts, error types), not platform-specific messages.
  • Assert specific expected values — never assert that a value is merely non-null or non-empty when a concrete value is available from seed data.
  • Avoid testing code paths that do not exist or asserting behavior that cannot occur.
  • Avoid redundant assertions across tests targeting the same method.
Step 5: Review determinism
Re-examine every assertion against non-null values. Confirm each is deterministic against the seeded data. Fix any assertion that depends on database state outside the test's control.
测试创建:
- [ ] 步骤1: 了解测试项目约定
- [ ] 步骤2: 识别可测试的数据访问构件
- [ ] 步骤3: 创建种子数据
- [ ] 步骤4: 编写测试用例
- [ ] 步骤5: 检查确定性
步骤1: 了解测试项目约定
阅读基础测试类、种子管理器和项目文件，以理解继承模式、事务管理和种子文件约定。
步骤2: 识别可测试的数据访问构件
仅针对目标项目。列出与数据库交互的数据访问方法——包括仓储、DAO、存储过程调用器、查询构建器。
步骤3: 创建种子数据
  • 遵循现有项目中的种子文件位置和命名约定。
  • 尽可能重用现有种子文件。
  • 避免使用
    TRUNCATE TABLE
    ——保留现有数据库数据的完整性。
  • 不要提交种子数据；测试在事务中运行，执行后会回滚。
  • 确保种子数据不会与其他测试冲突。
  • 在断言依赖种子数据之前，先加载并验证种子数据。
步骤4: 编写测试用例
  • 继承自基础测试类，以自动创建/回滚事务。
  • 断言逻辑输出（行、列、计数、错误类型），而非平台特定的消息。
  • 断言具体的预期值——当可以从种子数据中获取具体值时，绝不要仅断言值非空或非空字符串。
  • 避免测试不存在的代码路径，或断言不会发生的行为。
  • 针对同一方法的测试，避免重复断言。
步骤5: 检查确定性
重新检查所有针对非空值的断言。确认每个断言相对于种子数据都是确定性的。修复任何依赖于测试控制范围外数据库状态的断言。

Key Constraints

关键约束

  • Oracle is the golden source — tests capture Oracle's expected behavior.
  • DB-agnostic assertions — no platform-specific error messages or syntax in assertions.
  • Seed only against Oracle — test project will be migrated to PostgreSQL later.
  • Scoped to one project — do not create tests for artifacts outside the target project.
  • Oracle是基准源——测试需捕获Oracle的预期行为。
  • 与数据库无关的断言——断言中不得包含平台特定的错误消息或语法。
  • 仅针对Oracle生成种子数据——测试项目稍后会迁移到PostgreSQL。
  • 仅针对单个项目——不要为目标项目之外的构件创建测试。