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

github/awesome-copilot

Create Oracle integration tests for .NET data access artifacts before PostgreSQL migration.

What is creating-oracle-to-postgres-migration-integration-tests?

Generates integration test cases targeting Oracle that capture expected behavior as the authoritative baseline for a .NET project. Use during Phase 3 of Oracle-to-PostgreSQL migration, before any PostgreSQL work begins. Tests are written to be logically portable so they survive Phase 6 migration without rewriting.

Discovers test project conventions and inheritance patterns
Identifies testable data access artifacts (repositories, DAOs, stored procedures, query builders)
Creates seed data following project conventions without truncating existing tables
Writes integration test cases that inherit from base test class with automatic transaction rollback
Validates assertion determinism and portability across database platforms

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

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

Prerequisites

Target test project must already exist and compile
Existing base test class and seed manager conventions must be documented
Project file structure and transaction management patterns must be understood

Claude Code

Cursor

Windsurf

Cline

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

1.Step 1: Read the base test class, seed manager, and project file to understand inheritance and transaction patterns
2.Step 2: List all data access methods in the target project that interact with the database
3.Step 3: Create seed data following project conventions, avoiding truncation and ensuring collision-safety
4.Step 4: Write test cases inheriting from the base test class with specific assertions against seeded data
5.Step 5: Review every assertion for determinism and confirm it depends only on seeded data

Use cases

Good for

Establishing Oracle behavior baseline before migrating a .NET data access layer to PostgreSQL
Creating comprehensive test coverage for repositories and DAOs in Phase 3 of migration
Ensuring seed data is collision-safe and does not interfere with existing business or lookup rows
Writing assertions that validate logical outputs rather than platform-specific error messages
Preparing tests for Phase 6 migration by avoiding Oracle-specific syntax in assertions

Who it's for

Database migration engineers managing Oracle-to-PostgreSQL transitions
QA engineers creating integration tests for .NET data access layers
Development teams in Phase 3 of a structured migration workflow
Teams needing to establish deterministic test baselines before platform migration

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

When should I use this skill?

Use only during Phase 3, before any PostgreSQL migration work has begun. Do not invoke during Phase 6 or against a project that has already been migrated to PostgreSQL.

Should I test code paths that do not exist?

No. Avoid testing code paths that do not exist or asserting behavior that cannot occur. Focus on actual, testable data access methods.

How should I handle existing database data?

Never truncate or wipe pre-existing business or lookup rows. Add only minimal, collision-safe seed records needed for your test scenario.

What should assertions validate?

Assert logical outputs (rows, columns, counts, error types) and specific expected values from seed data, not platform-specific messages or syntax.

Why avoid platform-specific assertions?

Tests must survive Phase 6 migration to PostgreSQL without rewriting. Use Oracle column precision and logical assertions that work across both databases.

Full instructions (SKILL.md)

Source of truth, from github/awesome-copilot.

name: creating-oracle-to-postgres-migration-integration-tests description: 'Creates integration test cases targeting Oracle for .NET data access artifacts. Tests capture Oracle expected behavior as the authoritative baseline; they are written once and later ported to PostgreSQL by migrating the test project in Phase 6. Use only during Phase 3, before any PostgreSQL migration work has begun. Do not invoke during Phase 6 or against a project that has already been migrated.'

Creating Integration Tests for Oracle-to-PostgreSQL Migration

Generates integration test cases for data access artifacts in a single target project. Tests target Oracle and capture its behavior as the authoritative baseline. They are written to be logically portable — so they can survive Phase 6 migration without rewriting — but they do not run against PostgreSQL at this stage.

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.
Avoid TRUNCATE TABLE — keep existing database data intact.
Assume existing business rows and lookup rows are already present; add only minimal, collision-safe seed records needed for the scenario.
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.
Create or reuse a test LookupConstants class for stable lookup IDs/codes used across seed builders and assertions.

Step 4: Write test cases

Inherit from the base test class to get automatic transaction create/rollback.
Ensure each database-touching method in scope has at least one integration test (or multiple tests for higher-risk behavior branches).
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.
For text parameters, include both empty-string and NULL/missing input coverage where applicable.
For datetime behavior, include assertions that validate the value written and read back matches — use the Oracle column's precision (e.g., seconds-only for a date/time column with no fractional seconds) rather than assuming any particular database type syntax.

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

Phase 3 only — these tests target Oracle. Do not invoke this skill during Phase 6 or against a PostgreSQL-targeting project.
Oracle is the golden source — tests capture Oracle's expected behavior.
Assertion portability — avoid platform-specific error messages or syntax in assertions so that when the test project is migrated to PostgreSQL in Phase 6, assertions require no changes.
Seed only against Oracle — the test project will be migrated to PostgreSQL in Phase 6; seed data and infrastructure stay Oracle-targeted until then.
Scoped to one project — do not create tests for artifacts outside the target project.
Preserve existing data — never rewrite or wipe pre-existing business or lookup rows.