PluginBench
Skill
Official
Pass
Audit score 90

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

github/awesome-copilot

Generate xUnit integration tests for Oracle-to-PostgreSQL .NET data access migrations with deterministic seed data.

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

Creates DB-agnostic integration test cases for .NET data access artifacts during Oracle-to-PostgreSQL migrations. Generates xUnit tests with deterministic seed data that validate behavior consistency across both database systems. Use this when creating integration tests for migrated projects, generating test coverage for data access layers, or validating Oracle-to-PostgreSQL migration behavior.

  • Generates xUnit integration test cases scoped to a single target project
  • Creates deterministic seed data following project conventions
  • Produces DB-agnostic assertions that work against both Oracle and PostgreSQL
  • Validates data access method behavior (repositories, DAOs, stored procedure callers)
  • Ensures tests run in transactions with automatic rollback
  • Captures Oracle behavior as the golden source for migration validation

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
  • Base test class and seed manager conventions must be documented in the project
  • Read existing test project structure before generating new tests
Claude Code
Cursor
Windsurf
Cline

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

  1. 1.Discover the test project's base test class, seed manager, and naming conventions
  2. 2.Identify testable data access artifacts in the target project (repositories, DAOs, stored procedures)
  3. 3.Create seed data following project conventions, reusing existing seed files where possible
  4. 4.Write test cases inheriting from the base test class with DB-agnostic assertions
  5. 5.Review all assertions for determinism against seeded data and fix any external dependencies

Use cases

Good for
  • Writing integration tests for a newly migrated .NET data access project
  • Generating test coverage for repositories and DAOs during Oracle-to-PostgreSQL migration
  • Validating that data access behavior remains consistent after database platform migration
  • Creating seed data and test cases for stored procedure callers and query builders
  • Ensuring deterministic test execution across multiple database platforms
Who it's for
  • Backend engineers migrating .NET applications from Oracle to PostgreSQL
  • QA engineers validating data access layer behavior post-migration
  • Development teams creating integration test suites for database migrations
  • Architects designing migration validation strategies

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

Can I create tests for multiple projects at once?

No, this skill is scoped to a single target project only. Create tests for each project separately.

Should I seed data against PostgreSQL or Oracle?

Seed only against Oracle, as it is the golden source. The test project will be migrated to PostgreSQL later.

What if I need to test existing database state?

Avoid testing code paths that depend on database state outside the test's control. Load and verify seed data before assertions depend on it.

Can I use TRUNCATE TABLE in seed data?

No, avoid TRUNCATE TABLE to keep existing database data intact. Tests run in transactions that roll back automatically.

How do I ensure assertions are deterministic?

Assert specific expected values from seed data, never just non-null or non-empty. Re-examine every assertion to confirm it depends only on seeded data.

Full instructions (SKILL.md)

Source of truth, from github/awesome-copilot.


name: creating-oracle-to-postgres-migration-integration-tests description: 'Creates integration test cases for .NET data access artifacts during Oracle-to-PostgreSQL database migrations. Generates DB-agnostic xUnit tests with deterministic seed data that validate behavior consistency across both database systems. Use when creating integration tests for a migrated project, generating test coverage for data access layers, or writing Oracle-to-PostgreSQL migration validation 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.