사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/github/awesome-copilot --skill planning-oracle-to-postgres-migration-integration-testing시작 전 확인
- 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
- 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
Planning Integration Testing for Oracle-to-PostgreSQL Migration
Analyze a single target project to identify data access artifacts that require integration testing, then produce a structured, actionable testing plan.
Workflow
Progress:
- [ ] Step 1: Identify data access artifacts
- [ ] Step 2: Classify testing priorities
- [ ] Step 3: Write the testing planStep 1: Identify data access artifacts
Scope to the target project only. Find classes and methods that interact directly with the database — repositories, DAOs, stored procedure callers, service layers performing CRUD operations.
Step 2: Classify testing priorities
Rank artifacts by migration risk. Prioritize methods that use Oracle-specific features (refcursors, TO_CHAR, implicit type coercion, NO_DATA_FOUND) over simple CRUD.
Step 3: Write the testing plan
Write a markdown plan covering:
- List of testable artifacts with method signatures
- Recommended test cases per artifact
- Seed data requirements
- Known Oracle→PostgreSQL behavioral differences to validate
- Coverage mapping that ensures every database touchpoint has at least one test case (or a justified set of cases for high-risk methods)
When defining recommended test cases, explicitly include:
- Text parameter behavior for both empty string and
NULL/missing values. - Datetime/timezone assertions, including round-trip and comparison behavior.
- Cases where destination columns use
timestamp without time zoneortimestamp(0), with explicit timezone-application expectations.
Output
Write the plan to: .github/oracle-to-postgres-migration/Reports/{TARGET_PROJECT} Integration Testing Plan.md
Key Constraints
- Single project scope — only plan tests for artifacts within the target project.
- Database interactions only — skip business logic that does not touch the database.
- Oracle is the golden source — tests should capture Oracle's expected behavior for comparison against PostgreSQL.
- No multi-connection harnessing — migrated applications are copied and renamed (e.g.,
MyApp.Postgres), so each instance targets one database.
