Creating Oracle To Postgres Migration Integration Tests
Generate xUnit integration tests with shared seed data so Oracle and PostgreSQL behave the same after a .NET database migration.
Overview
Creating Oracle-to-Postgres Migration Integration Tests is an agent skill most often used in Ship (also Build backend) that generates DB-agnostic xUnit integration tests with deterministic seed data for Oracle-to-Postgre
Install
npx skills add https://github.com/github/awesome-copilot --skill creating-oracle-to-postgres-migration-integration-testsWhat is this skill?
- Five-step workflow: discover conventions, find artifacts, seed data, write tests, review determinism
- DB-agnostic xUnit tests for a single target .NET project with Oracle vs PostgreSQL parity
- Deterministic seed data via existing seed manager patterns in the scaffolded test project
- Scoped to repositories and data-access methods that hit the database in the migration target
- 5-step test creation workflow with explicit determinism review
- Scopes test generation to one target .NET project at a time
Adoption & trust: 1.6k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You migrated or are migrating a .NET app from Oracle to PostgreSQL but lack integration tests that prove the same data-access behavior on both databases.
Who is it for?
.NET maintainers with an existing test scaffold who need repeatable cross-database integration coverage during an Oracle-to-Postgres migration.
Skip if: Greenfield apps on a single database, projects without a compiling test project, or teams wanting automated schema migration scripts instead of behavioral tests.
When should I use this skill?
When creating integration tests for a migrated project, generating test coverage for data access layers, or writing Oracle-to-PostgreSQL migration validation tests.
What do I get? / Deliverables
You get scoped xUnit integration tests and seed data that run against Oracle or PostgreSQL so CI can catch parity breaks before production cutover.
- Deterministic seed data files aligned to project seed manager conventions
- DB-agnostic xUnit integration test classes for identified data-access methods
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Migration validation is canonical on Ship testing because the goal is proving cross-DB consistency before release, even though artifacts live in the data-access build layer. Integration tests and determinism checks are the core deliverable—testing subphase is the right primary shelf.
Where it fits
After swapping EF or ADO providers, you generate tests for each new repository method before merging the migration branch.
You run the same xUnit suite against Oracle and PostgreSQL connection strings in CI to gate release.
Post-cutover regressions add tests for production bug fixes to keep dual-provider parity during a staggered decommission of Oracle.
How it compares
Focused migration validation tests—not generic unit-test tutoring or EF-only snapshot tooling.
Common Questions / FAQ
Who is creating-oracle-to-postgres-migration-integration-tests for?
Solo and small-team .NET developers executing Oracle-to-PostgreSQL migrations who need integration coverage that exercises real database calls with shared seeds.
When should I use creating-oracle-to-postgres-migration-integration-tests?
In Ship testing while validating a migrated data layer; in Build backend when adding repositories or stored-procedure access you must prove on both Oracle and Postgres; before launch when CI must gate provider switches.
Is creating-oracle-to-postgres-migration-integration-tests safe to install?
Review SKILL.md and the Security Audits panel on this page; the skill expects reading your test project and writing tests—avoid pointing it at production connection strings or secrets in agent context.
SKILL.md
READMESKILL.md - Creating Oracle To Postgres Migration Integration Tests
# Creating Integration Tests for Oracle-to-PostgreSQL Migration Generates integration test cases for data access artifacts in a single target project. Tests validate behavior consistency when running against Oracle or 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. ## 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.