Oleksandr Bezdieniezhnykh
cbf370c765
- Changed the directory structure for task specifications to include a dedicated `todo/` folder within `_docs/02_tasks/` for tasks ready for implementation. - Updated references in various skills and documentation to reflect the new task lifecycle, including changes in the `implementer` and `decompose` skills. - Enhanced the README and flow documentation to clarify the new task organization and its implications for the implementation process. These updates improve task management clarity and streamline the implementation workflow.
3.0 KiB
Negative Input Tests
Task: AZ-144_test_negative Name: Negative Input Tests Description: Implement E2E tests verifying proper error responses for invalid inputs, unavailable engine, and missing configuration Complexity: 2 points Dependencies: AZ-138_test_infrastructure Component: Integration Tests Jira: AZ-144 Epic: AZ-137
Problem
The system must handle invalid and edge-case inputs gracefully, returning appropriate HTTP error codes without crashing. Tests must verify error responses for empty files, corrupt data, engine unavailability, and missing configuration.
Outcome
- Empty image returns 400 Bad Request
- Corrupt/non-image data returns 400 Bad Request
- Detection when engine unavailable returns 503 or 422
- Missing classes.json prevents normal operation
- Service remains healthy after all negative inputs
Scope
Included
- FT-N-01: Empty image returns 400
- FT-N-02: Invalid image data returns 400
- FT-N-03: Detection when engine unavailable returns 503
- FT-N-05: Missing classes.json prevents startup
Excluded
- Duplicate media_id (covered in async/SSE tests)
- Service outage scenarios (covered in resilience tests)
- Malformed multipart payloads (covered in security tests)
Acceptance Criteria
AC-1: Empty image Given the detections service is running When POST /detect is called with a zero-byte file Then response is 400 Bad Request with error message
AC-2: Corrupt image Given the detections service is running When POST /detect is called with random binary data Then response is 400 Bad Request (not 500)
AC-3: Engine unavailable Given mock-loader is configured to fail model requests When POST /detect is called Then response is 503 or 422 with no crash or unhandled exception
AC-4: Missing classes.json Given detections service started without classes.json volume mount When the service runs or a detection is attempted Then service either fails to start or returns empty/error results without crashing
Non-Functional Requirements
Reliability
- Service must remain operational after processing invalid inputs (AC-1, AC-2)
Integration Tests
| AC Ref | Initial Data/Conditions | What to Test | Expected Behavior | NFR References |
|---|---|---|---|---|
| AC-1 | Service running | POST /detect with empty file | 400 Bad Request | Max 5s |
| AC-2 | Service running | POST /detect with corrupt binary | 400 Bad Request | Max 5s |
| AC-3 | mock-loader returns 503 | POST /detect with valid image | 503 or 422 | Max 30s |
| AC-4 | No classes.json mounted | Start service or detect | Fail gracefully | Max 30s |
Constraints
- AC-4 requires a separate Docker Compose configuration without the classes.json volume
- AC-3 requires mock-loader control API to simulate failure
Risks & Mitigation
Risk 1: AC-4 service start behavior
- Risk: Behavior when classes.json is missing may vary (fail at start vs. fail at detection)
- Mitigation: Test both paths; accept either as valid graceful handling