planning-oracle-to-postgres-migration-integration-testing

分析单个 .NET 项目中与数据库交互的 repositories、DAO、存储过程调用和服务层，按迁移风险分类，并生成 Markdown 集成测试计划，包含可测试制品、推荐测试用例、种子数据、Oracle→PostgreSQL 行为差异和覆盖率映射。仅覆盖目标项目内的数据库交互。

github

热度 0.00

最近更新 2026-10-18 22:10:55

分类：开发依赖：读写文件应用场景：报告撰写 / 工作流 / 数据处理 / 代码审查

安装技能

复制下面的话术发给你的 Agent，它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill： npx secure-skills-cli add github/awesome-copilot/planning-oracle-to-postgres-migration-integration-testing

Metadata

name: planning-oracle-to-postgres-migration-integration-testing
description: Creates an integration testing plan for .NET data access artifacts during Oracle-to-PostgreSQL database migrations. Analyzes a single project to identify repositories, DAOs, and service layers that interact with the database, then produces a structured testing plan. Use when planning integration test coverage for a migrated project, identifying which data access methods need tests, or preparing for Oracle-to-PostgreSQL migration validation.

Planning Integration Testing for Oracle-to-PostgreSQL Migration

Analyze a single target project to identify data access artifacts that require integration testing, then produce a structured, actionable testing plan.

Workflow

Progress:
- [ ] Step 1: Identify data access artifacts
- [ ] Step 2: Classify testing priorities
- [ ] Step 3: Write the testing plan

Step 1: Identify data access artifacts

Scope to the target project only. Find classes and methods that interact directly with the database — repositories, DAOs, stored procedure callers, service layers performing CRUD operations.

Step 2: Classify testing priorities

Rank artifacts by migration risk. Prioritize methods that use Oracle-specific features (refcursors, TO_CHAR, implicit type coercion, NO_DATA_FOUND) over simple CRUD.

Step 3: Write the testing plan

Write a markdown plan covering:

List of testable artifacts with method signatures
Recommended test cases per artifact
Seed data requirements
Known Oracle→PostgreSQL behavioral differences to validate
Coverage mapping that ensures every database touchpoint has at least one test case (or a justified set of cases for high-risk methods)

When defining recommended test cases, explicitly include:

Text parameter behavior for both empty string and NULL/missing values.
Datetime/timezone assertions, including round-trip and comparison behavior.
Cases where destination columns use timestamp without time zone or timestamp(0), with explicit timezone-application expectations.

Output

Write the plan to: .github/oracle-to-postgres-migration/Reports/{TARGET_PROJECT} Integration Testing Plan.md

Key Constraints

Single project scope — only plan tests for artifacts within the target project.
Database interactions only — skip business logic that does not touch the database.
Oracle is the golden source — tests should capture Oracle's expected behavior for comparison against PostgreSQL.
No multi-connection harnessing — migrated applications are copied and renamed (e.g., MyApp.Postgres), so each instance targets one database.