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

github/awesome-copilot

Plan integration tests for .NET Oracle-to-PostgreSQL migrations by analyzing data access artifacts.

What is planning-oracle-to-postgres-migration-integration-testing?

This skill analyzes a single .NET project to identify repositories, DAOs, and service layers that interact with databases, then generates a structured integration testing plan for Oracle-to-PostgreSQL migrations. Use it when preparing migration validation, determining test coverage for data access methods, or planning integration tests for migrated projects.

Identifies data access artifacts (repositories, DAOs, stored procedure callers, service layers) within a target project
Classifies testing priorities by migration risk, emphasizing Oracle-specific features like refcursors and implicit type coercion
Generates a markdown testing plan with testable artifacts, method signatures, and recommended test cases
Documents seed data requirements and Oracle-to-PostgreSQL behavioral differences to validate
Produces output to `.github/oracle-to-postgres-migration/Reports/{TARGET_PROJECT} Integration Testing Plan.md`

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

npx skills add https://github.com/github/awesome-copilot --skill planning-oracle-to-postgres-migration-integration-testing

Prerequisites

A .NET project with data access artifacts (repositories, DAOs, service layers)
Access to the target project's source code for artifact analysis
Understanding of the project's database interaction patterns

Claude Code

Cursor

Windsurf

Cline

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

1.Install the skill using the provided npm command
2.Specify the target .NET project to analyze
3.Review the generated testing plan in `.github/oracle-to-postgres-migration/Reports/{TARGET_PROJECT} Integration Testing Plan.md`
4.Use the artifact list and test case recommendations to build integration tests
5.Reference the Oracle-to-PostgreSQL behavioral differences section when writing test assertions

Use cases

Good for

Planning integration test coverage for a .NET project being migrated from Oracle to PostgreSQL
Identifying which data access methods require tests before database migration validation
Preparing a structured testing strategy that captures Oracle behavior as the baseline for PostgreSQL comparison
Documenting seed data and test cases for Oracle-specific features (refcursors, TO_CHAR, implicit type coercion)
Validating behavioral differences between Oracle and PostgreSQL implementations in migrated applications

Who it's for

Database migration engineers planning Oracle-to-PostgreSQL transitions
QA teams designing integration test suites for .NET applications
.NET developers preparing data access layers for database platform changes
Migration project leads needing structured testing plans and artifact inventories

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

Does this skill analyze multiple projects at once?

No. The skill is scoped to a single target project only. Run it separately for each project requiring migration testing.

What types of database interactions does it identify?

It identifies repositories, DAOs, stored procedure callers, and service layer methods that perform CRUD operations or direct database interactions. Business logic without database touches is excluded.

How does it prioritize which artifacts to test?

It ranks artifacts by migration risk, prioritizing methods using Oracle-specific features (refcursors, TO_CHAR, implicit type coercion, NO_DATA_FOUND) over simple CRUD operations.

Can it test applications connected to both Oracle and PostgreSQL simultaneously?

No. The skill assumes migrated applications are copied and renamed (e.g., MyApp.Postgres), with each instance targeting a single database.

What does the output testing plan include?

The plan includes a list of testable artifacts with method signatures, recommended test cases per artifact, seed data requirements, and documented Oracle-to-PostgreSQL behavioral differences to validate.

Full instructions (SKILL.md)

Source of truth, from github/awesome-copilot.

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

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.