Planning Oracle To Postgres Migration Integration Testing
Produce a scoped integration-test plan for .NET data-access code after an Oracle-to-PostgreSQL migration.
Overview
Planning Oracle-to-Postgres Migration Integration Testing is an agent skill most often used in Ship (also Build) that analyzes one .NET project and outputs a prioritized integration-testing plan for PostgreSQL migration
Install
npx skills add https://github.com/github/awesome-copilot --skill planning-oracle-to-postgres-migration-integration-testingWhat is this skill?
- Three-step workflow: discover artifacts, rank migration risk, write the markdown testing plan
- Scopes analysis to a single target .NET project—repositories, DAOs, stored-procedure callers, CRUD services
- Prioritizes Oracle-specific behaviors (refcursors, `TO_CHAR`, implicit coercion, `NO_DATA_FOUND`) over trivial CRUD
- Deliverable lists testable methods with signatures and recommended test cases
- 3-step workflow: identify artifacts, classify priorities, write testing plan
Adoption & trust: 1.5k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You migrated a .NET app to PostgreSQL but do not know which repositories and DAO methods need integration tests or which Oracle-specific calls will fail silently.
Who is it for?
Indie or team maintainers mid Oracle-to-PostgreSQL migration with a single .NET service whose DB boundary you must regression-test before ship.
Skip if: Greenfield apps with no legacy Oracle, non-.NET stacks, or teams that only need SQL schema diff tools without application-layer test planning.
When should I use this skill?
Planning integration test coverage for a migrated project, identifying which data access methods need tests, or preparing Oracle-to-PostgreSQL migration validation.
What do I get? / Deliverables
You get a markdown testing plan listing data-access artifacts, risk-ranked methods, and recommended cases so implementation can start immediately.
- Markdown integration testing plan
- List of testable artifacts with method signatures
- Risk-ranked test case recommendations
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Migration validation belongs in Ship when you prove data access still behaves on PostgreSQL before release. Integration testing is the concrete subphase for exercising repositories, DAOs, and DB-touching services against the new database.
Where it fits
Generate a prioritized test matrix for stored-procedure callers before tagging the PostgreSQL release candidate.
While refactoring a repository off Oracle types, list which methods still need parity tests on PostgreSQL.
After production oddities, extend the plan with missing integration cases for implicit coercion paths.
How it compares
Use for migration-focused integration test planning on .NET data layers, not for generic unit-test generation unrelated to database dialect changes.
Common Questions / FAQ
Who is planning-oracle-to-postgres-migration-integration-testing for?
.NET developers and tech leads validating data access after Oracle-to-PostgreSQL migrations who need a checklist tied to real repositories and services in one project.
When should I use planning-oracle-to-postgres-migration-integration-testing?
In Ship while planning regression coverage; in Build when mapping which DAO and repository methods still assume Oracle semantics before you freeze the migration branch.
Is planning-oracle-to-postgres-migration-integration-testing safe to install?
It guides analysis and documentation only; confirm repo trust and review the Security Audits panel on this Prism page before installing skills from awesome-copilot.
SKILL.md
READMESKILL.md - Planning Oracle To Postgres Migration Integration Testing
# 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 ## 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.