56 lines
2.9 KiB
Markdown
56 lines
2.9 KiB
Markdown
# Testing Strategy: Template Mapping Engine
|
|
|
|
This document outlines the testing strategy for the Template Mapping Engine to ensure production readiness.
|
|
|
|
## 1. Backend Testing (Python/FastAPI)
|
|
|
|
### Unit Testing
|
|
* **Framework**: `pytest`
|
|
* **Database**: Use an in-memory SQLite database (`sqlite:///:memory:`) or a dedicated test PostgreSQL container via `testcontainers`.
|
|
* **Mocks**:
|
|
* Mock OCR engines (`pytesseract`, `pdfplumber`) to avoid slow I/O during test suites.
|
|
* Mock file uploads using `fastapi.testclient.TestClient`.
|
|
* **Coverage Targets**:
|
|
* **Engines**: 100% logic coverage for `TemplateRecognitionEngine` and scoring weights.
|
|
* **Services**: 90% coverage for CRUD operations.
|
|
|
|
### Integration Testing
|
|
* Test end-to-end API flows:
|
|
1. `POST /api/documents/upload` with a sample PDF.
|
|
2. Wait for layout extraction.
|
|
3. `POST /api/templates` to create a template.
|
|
4. `POST /api/templates/{id}/mappings/save` to map extracted data.
|
|
5. `POST /api/documents/upload` with a similar document to verify `POST /api/documents/{id}/recognize` returns the correct template match.
|
|
|
|
## 2. Frontend Testing (Angular)
|
|
|
|
### Unit Testing
|
|
* **Framework**: Jasmine & Karma (or Jest if configured).
|
|
* **Component Tests**:
|
|
* Verify `TemplatesComponent` renders the left and right panels.
|
|
* Verify the `AddField` dialog toggles correctly and validates empty inputs.
|
|
* **Service Tests**:
|
|
* Mock `HttpClient` using `HttpTestingController` to ensure `TemplateService` sends correct payloads to the backend.
|
|
|
|
### E2E / Integration Testing
|
|
* **Framework**: Cypress or Playwright.
|
|
* **Critical User Journeys (CUJ)**:
|
|
1. User uploads a document, UI displays the layout preview visually.
|
|
2. User creates a template and adds 3 fields.
|
|
3. User drags a block from the Document Preview and drops it into a Template Field.
|
|
4. User saves the mapping successfully.
|
|
|
|
## 3. OCR & Layout Extraction Accuracy Testing
|
|
|
|
Since the OCR engine relies on visual heuristics rather than AI models, testing its accuracy is crucial to prevent regressions.
|
|
|
|
* **Golden Dataset**: Create a dataset of 50-100 real-world business documents (Invoices, POs, Receipts).
|
|
* **Evaluation Metric**: Run the `DocumentProcessor` over the Golden Dataset and compare the output bounding boxes and classifications (HEADER, VENDOR, etc.) against manually annotated Ground Truth data.
|
|
* **Acceptance Criteria**: Maintain > 92% classification accuracy for logical block types.
|
|
|
|
## 4. Performance & Load Testing
|
|
|
|
* **Tool**: `locust` or `k6`.
|
|
* **Scenario**: Simulate 50 concurrent users uploading 2MB PDF documents simultaneously to ensure the `DocumentProcessor` does not exhaust server memory (OpenCV and Tesseract can be memory-intensive).
|
|
* **Optimization**: Ensure the `process_file` logic can be offloaded to Celery workers if the API starts blocking or timing out under load.
|