# 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