[Chore] PDF·DOCX 파싱 사후 리뷰 반영 - 검증 문서 보완, 빈 Page 회귀 테스트, Chunker 중복 순회 정리 - #115
Merged
Conversation
기존 테스트는 빈 Page만 있는 PDF의 OCR 필요 오류만 검증해, Page 자체가 0개인 PDF가 다른 오류로 분기한다는 사실이 테스트로 고정돼 있지 않았다. Page가 없으면 OCR로도 복구할 수 없으므로 스캔 PDF와 구분해 DOCUMENT_CONTENT_EMPTY를 반환해야 한다. 이 분기가 이후 리팩터링에서 OCR 필요 오류로 합쳐지지 않도록 회귀 테스트를 추가한다.
chunk(ParsedDocument)는 Segment 길이를 codePointCount로 한 번 순회하고, appendSegmentChunks가 같은 Text를 codePoints().toArray()로 다시 순회했다. Segment 수가 많은 PDF와 DOCX에서 문서 전체를 두 번 훑는 비용이 생긴다. appendSegmentChunks가 이미 만든 Code Point 배열의 길이를 반환하도록 바꿔 호출부가 그 값을 그대로 사용하게 한다. Chunk 경계, 전역 Offset, page_no와 section_title 결과는 달라지지 않는다.
Swagger 수동 검증 중 발견했다. 업로드 API의 Operation description과 file 필드 Schema가 아직 "TXT 또는 Markdown"으로 남아 있어, PDF와 DOCX를 추가한 이후의 실제 동작과 프론트가 보는 계약이 어긋난다. 지원 형식을 실제와 맞추고, 확장자와 Content-Type이 함께 맞아야 한다는 점과 구형 DOC 형식은 지원하지 않는다는 점을 명시한다.
검증 문서가 단위·통합 테스트 결과만 담고 있어 Swagger로 노출되는 업로드 API의 수동 검증 결과가 빠져 있었다. 로컬에 애플리케이션을 기동하고 Swagger가 노출하는 것과 동일한 Endpoint와 Schema로 허용 2건과 거부 3건을 실제 호출해 요청, 기대 결과, 실제 응답을 기록한다. 5개 조합 모두 기존 단위 테스트 결과와 일치했다. UI의 File Picker 조작만 자동화가 어려워 요청 전송에 CLI를 사용했다는 사실과 검증용 Schema, Bucket, 계정을 모두 일회용으로 만들고 삭제했다는 사실을 함께 남긴다. Page가 없는 PDF의 오류 코드도 회귀 테스트 추가에 맞춰 반영한다.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughPDF·DOCX 업로드 검증 문서와 API 설명을 보완했습니다. 페이지가 없는 PDF의 회귀 테스트를 추가했습니다. Changes문서 업로드 계약 및 검증
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
배경
PR #107(PDF·DOCX 문서 파싱)은 자동 리뷰가 끝나기 전에 머지됐고, 머지 직후 등록된 지적 3건을 #110으로 분리해 처리했습니다. 모두 동작 오류가 아닌 문서·테스트·성능 보완 사항입니다.
1. Page가 없는 PDF 회귀 테스트 추가
기존 테스트는 빈 Page만 있는 PDF의
DOCUMENT_OCR_REQUIRED만 검증했고, Page 자체가 0개인 PDF가DOCUMENT_CONTENT_EMPTY로 분기한다는 사실은 테스트로 고정돼 있지 않았습니다. Page가 없으면 OCR로도 복구할 수 없어 스캔 PDF와 구분해야 하므로, 이 분기가 이후 리팩터링에서 합쳐지지 않도록 회귀 테스트를 추가했습니다.2. FixedSizeChunker 중복 순회 제거
chunk(ParsedDocument)가 Segment 길이를codePointCount(...)로 한 번 순회하고,appendSegmentChunks가 같은 Text를codePoints().toArray()로 다시 순회하고 있었습니다. Segment가 많은 PDF·DOCX에서 문서 전체를 두 번 훑습니다.appendSegmentChunks가 이미 만든 Code Point 배열의 길이를 반환하도록 바꿔 호출부가 그대로 사용하게 했습니다. Segment당 순회가 2회에서 1회로 줄고, Chunk 경계·전역 Offset·page_no·section_title결과는 달라지지 않습니다. 청커 단위 10건과 Chunking 통합 5건으로 회귀 확인했습니다.3. Swagger 수동 검증 결과 기록
검증 문서가 단위·통합 테스트 결과만 담고 있어, 실제로 애플리케이션을 기동해 검증하고 결과를 8절에 추가했습니다.
pdfapplication/pdf201,jobStatus = PENDINGdocx...wordprocessingml.document201,jobStatus = PENDINGpdfapplication/octet-stream400,DOCUMENT-FILE-004docxapplication/pdf400,DOCUMENT-FILE-004docapplication/msword400,DOCUMENT-FILE-0035개 조합 모두 기존 단위 테스트 결과와 일치했습니다. Swagger UI(
/swagger-ui/index.html200)와/v3/api-docs의POST /api/documents노출도 확인했고, Swagger UI가 노출하는 것과 동일한 Endpoint·Schema로 같은multipart/form-data요청을 보냈습니다. UI의 File Picker 조작만 자동화가 어려워 요청 전송에는 CLI를 사용했으며, 그 사실을 문서에 명시했습니다.검증용 Schema, Bucket, 계정은 모두 일회용으로 만들고 검증 후 삭제했습니다. 기존 개발 Schema와 데이터는 변경하지 않았고, 테스트용 PDF·DOCX·DOC 파일은 저장소 밖 임시 경로에서 생성해 저장소에 추가하지 않았습니다.
4. 업로드 API의 낡은 지원 형식 설명 정정 (검증 중 발견)
Swagger를 확인하는 과정에서 업로드 API의 Operation description과
file필드 Schema가 아직 "TXT 또는 Markdown"으로 남아 있는 것을 발견했습니다. PDF·DOCX 추가 이후의 실제 동작과 프론트가 보는 계약이 어긋나 함께 고쳤습니다. 지원 형식을 실제와 맞추고, 확장자와 Content-Type이 함께 맞아야 한다는 점과 구형 DOC 형식은 지원하지 않는다는 점을 명시했습니다.테스트
Closes #110
Summary by CodeRabbit
새로운 기능
버그 수정
문서