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

Name: creating-oracle-to-postgres-migration-integration-tests
Author: github

1.7kinstalls4.6kforks

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

github/awesome-copilot/creating-oracle-to-postgres-migration-integration-tests

$npx -y skills add github/awesome-copilot --skill creating-oracle-to-postgres-migration-integration-tests

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	# Creating Integration Tests for Oracle-to-PostgreSQL Migration
2
3	Generates integration test cases for data access artifacts in a single target project. Tests validate behavior consistency when running against Oracle or PostgreSQL.
4
5	## Prerequisites
6
7	- The test project must already exist and compile (scaffolded separately).
8	- Read the existing base test class and seed manager conventions before writing tests.
9
10	## Workflow
11
12	```
13	Test Creation:
14	- [ ] Step 1: Discover the test project conventions
15	- [ ] Step 2: Identify testable data access artifacts
16	- [ ] Step 3: Create seed data
17	- [ ] Step 4: Write test cases
18	- [ ] Step 5: Review determinism
19	```
20
21	Step 1: Discover the test project conventions
22
23	Read the base test class, seed manager, and project file to understand inheritance patterns, transaction management, and seed file conventions.
24
25	Step 2: Identify testable data access artifacts
26
27	Scope to the target project only. List data access methods that interact with the database — repositories, DAOs, stored procedure callers, query builders.
28
29	Step 3: Create seed data
30
31	- Follow seed file location and naming conventions from the existing project.
32	- Reuse existing seed files when possible.
33	- Avoid `TRUNCATE TABLE` — keep existing database data intact.
34	- Assume existing business rows and lookup rows are already present; add only minimal, collision-safe seed records needed for the scenario.
35	- Do not commit seed data; tests run in transactions that roll back.
36	- Ensure seed data does not conflict with other tests.
37	- Load and verify seed data before assertions depend on it.
38	- Create or reuse a test `LookupConstants` class for stable lookup IDs/codes used across seed builders and assertions.
39
40	Step 4: Write test cases
41
42	- Inherit from the base test class to get automatic transaction create/rollback.
43	- Ensure each database-touching method in scope has at least one integration test (or multiple tests for higher-risk behavior branches).
44	- Assert logical outputs (rows, columns, counts, error types), not platform-specific messages.
45	- 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.
46	- Avoid testing code paths that do not exist or asserting behavior that cannot occur.
47	- Avoid redundant assertions across tests targeting the same method.
48	- For text parameters, include both empty-string and `NULL`/missing input coverage where applicable.
49	- For datetime behavior, include explicit timezone-sensitive assertions when methods write/read `timestamp without time zone` or `timestamp(0)` targets.
50
51	Step 5: Review determinism
52
53	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.
54
55	## Key Constraints
56
57	- Oracle is the golden source — tests capture Oracle's expected behavior.
58	- DB-agnostic assertions — no platform-specific error messages or syntax in assertions.
59	- Seed only against Oracle — test project will be migrated to PostgreSQL later.
60	- Scoped to one project — do not create tests for artifacts outside the target project.
61	- Preserve existing data — never rewrite or wipe pre-existing business or lookup rows.

People who liked this also viewed

6 picks

Type

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

1.7kinstalls4.6kforks

View on GitHub

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

github/awesome-copilot/creating-oracle-to-postgres-migration-integration-tests

$npx -y skills add github/awesome-copilot --skill creating-oracle-to-postgres-migration-integration-tests

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Creating Integration Tests for Oracle-to-PostgreSQL Migration
2
3	Generates integration test cases for data access artifacts in a single target project. Tests validate behavior consistency when running against Oracle or PostgreSQL.
4
5	## Prerequisites
6
7	- The test project must already exist and compile (scaffolded separately).
8	- Read the existing base test class and seed manager conventions before writing tests.
9
10	## Workflow
11
12	```
13	Test Creation:
14	- [ ] Step 1: Discover the test project conventions
15	- [ ] Step 2: Identify testable data access artifacts
16	- [ ] Step 3: Create seed data
17	- [ ] Step 4: Write test cases
18	- [ ] Step 5: Review determinism
19	```
20
21	Step 1: Discover the test project conventions
22
23	Read the base test class, seed manager, and project file to understand inheritance patterns, transaction management, and seed file conventions.
24
25	Step 2: Identify testable data access artifacts
26
27	Scope to the target project only. List data access methods that interact with the database — repositories, DAOs, stored procedure callers, query builders.
28
29	Step 3: Create seed data
30
31	- Follow seed file location and naming conventions from the existing project.
32	- Reuse existing seed files when possible.
33	- Avoid `TRUNCATE TABLE` — keep existing database data intact.
34	- Assume existing business rows and lookup rows are already present; add only minimal, collision-safe seed records needed for the scenario.
35	- Do not commit seed data; tests run in transactions that roll back.
36	- Ensure seed data does not conflict with other tests.
37	- Load and verify seed data before assertions depend on it.
38	- Create or reuse a test `LookupConstants` class for stable lookup IDs/codes used across seed builders and assertions.
39
40	Step 4: Write test cases
41
42	- Inherit from the base test class to get automatic transaction create/rollback.
43	- Ensure each database-touching method in scope has at least one integration test (or multiple tests for higher-risk behavior branches).
44	- Assert logical outputs (rows, columns, counts, error types), not platform-specific messages.
45	- 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.
46	- Avoid testing code paths that do not exist or asserting behavior that cannot occur.
47	- Avoid redundant assertions across tests targeting the same method.
48	- For text parameters, include both empty-string and `NULL`/missing input coverage where applicable.
49	- For datetime behavior, include explicit timezone-sensitive assertions when methods write/read `timestamp without time zone` or `timestamp(0)` targets.
50
51	Step 5: Review determinism
52
53	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.
54
55	## Key Constraints
56
57	- Oracle is the golden source — tests capture Oracle's expected behavior.
58	- DB-agnostic assertions — no platform-specific error messages or syntax in assertions.
59	- Seed only against Oracle — test project will be migrated to PostgreSQL later.
60	- Scoped to one project — do not create tests for artifacts outside the target project.
61	- Preserve existing data — never rewrite or wipe pre-existing business or lookup rows.

People who liked this also viewed

6 picks

Type