PluginBench
Skill
Official
Pass
Audit score 90

scaffolding-oracle-to-postgres-migration-test-project

github/awesome-copilot

Scaffold xUnit test infrastructure for Oracle-to-PostgreSQL migration validation in .NET.

What is scaffolding-oracle-to-postgres-migration-test-project?

Creates a compilable xUnit integration test project with transaction-rollback base class and seed data manager for validating Oracle-to-PostgreSQL database migrations in .NET solutions. Use this before writing migration integration tests to establish consistent test infrastructure that isolates each test with automatic rollback.

  • Generates an xUnit test project matching the target application's .NET version
  • Creates a transaction-rollback base class that automatically rolls back after each test
  • Implements a seed data manager for loading test data within transaction scope
  • Configures appsettings.json for Oracle database connectivity
  • Adds required NuGet packages (Oracle connectivity, xUnit) without upgrading versions
  • Verifies the test project compiles before completion

How to install scaffolding-oracle-to-postgres-migration-test-project

npx skills add https://github.com/github/awesome-copilot --skill scaffolding-oracle-to-postgres-migration-test-project
Prerequisites
  • Target .NET project with a .csproj file
  • Oracle database connectivity details for appsettings.json configuration
  • Existing seed data files (optional; naming convention will be established)
Claude Code
Cursor
Windsurf
Cline

How to use scaffolding-oracle-to-postgres-migration-test-project

  1. 1.Inspect the target project's .csproj to identify .NET version and package versions
  2. 2.Run the skill to generate the xUnit test project with matching .NET version
  3. 3.Review the generated transaction-rollback base class and seed data manager
  4. 4.Configure appsettings.json with Oracle database connection details
  5. 5.Build the test project and verify it compiles with zero errors
  6. 6.Begin writing test cases by inheriting from the generated base class

Use cases

Good for
  • Setting up test infrastructure before writing Oracle-to-PostgreSQL migration validation tests
  • Creating a reusable test project for a single target application in a .NET solution
  • Establishing seed data patterns and transaction isolation for database migration testing
  • Preparing integration tests that validate behavior consistency between Oracle and PostgreSQL
Who it's for
  • Backend engineers validating database migrations
  • QA engineers setting up migration test infrastructure
  • .NET developers testing Oracle-to-PostgreSQL data layer changes
  • Teams managing multi-database application transitions

scaffolding-oracle-to-postgres-migration-test-project FAQ

Do I need to create the test project manually first?

No. The skill creates the entire xUnit test project structure, including the .csproj file, base classes, and configuration. You only need to provide the target project path.

Will this upgrade my .NET version or NuGet packages?

No. The skill matches the target project's .NET version and existing package versions exactly without upgrades.

Does the seed data get committed to the database?

No. Seed data is loaded within the transaction scope and automatically rolled back after each test, preserving the original database state.

Can I reuse existing seed data files?

Yes. The skill establishes a naming convention for seed file location that you can follow, and will reuse existing seed files if available.

What happens if the test project doesn't compile?

The skill verifies compilation before completion and reports errors. You must resolve any compilation issues before using the test infrastructure.

Full instructions (SKILL.md)

Source of truth, from github/awesome-copilot.


name: scaffolding-oracle-to-postgres-migration-test-project description: 'Scaffolds an xUnit integration test project for validating Oracle-to-PostgreSQL database migration behavior in .NET solutions. Creates the test project, transaction-rollback base class, and seed data manager. Use when setting up test infrastructure before writing migration integration tests, or when a test project is needed for Oracle-to-PostgreSQL validation.'

Scaffolding an Integration Test Project for Oracle-to-PostgreSQL Migration

Creates a compilable, empty xUnit test project with transaction management and seed data infrastructure for a single target project. Run once per project before writing tests.

Workflow

Progress:
- [ ] Step 1: Inspect the target project
- [ ] Step 2: Create the xUnit test project
- [ ] Step 3: Implement transaction-rollback base class
- [ ] Step 4: Implement seed data manager
- [ ] Step 5: Verify the project compiles

Step 1: Inspect the target project

Read the target project's .csproj to determine the .NET version and existing package references. Match these versions exactly — do not upgrade.

Step 2: Create the xUnit test project

  • Target the same .NET version as the application under test.
  • Add NuGet packages for Oracle database connectivity and xUnit.
  • Add a project reference to the target project only — no other application projects.
  • Add an appsettings.json configured for Oracle database connectivity.

Step 3: Implement transaction-rollback base class

  • Create a base test class that opens a transaction before each test and rolls it back after.
  • Catch and handle all exceptions to guarantee rollback.
  • Make the pattern inheritable by all downstream test classes.

Step 4: Implement seed data manager

  • Create a global seed manager for loading test data within the transaction scope.
  • Do not commit seed data — transactions roll back after each test.
  • Do not use TRUNCATE TABLE — preserve existing database data.
  • Reuse existing seed files if available.
  • Establish a naming convention for seed file location that downstream test creation will follow.

Step 5: Verify the project compiles

Build the test project and confirm it compiles with zero errors before finishing.

Key Constraints

  • Oracle is the golden behavior source — scaffold for Oracle first.
  • Keep to existing .NET and C# versions; do not introduce newer language or runtime features.
  • Output is an empty test project with infrastructure only — no test cases.