REST API Simulator & Testing Framework
Python/Docker testing framework that scaled from a 7-person team tool to a framework used by 50+ engineers across Strategic Missions Division
Problem
Hardware API testing at L3Harris required physical devices, long feedback loops, and manual verification. A 7-person team had built a basic API simulator, but it was undocumented, inconsistent, and lacked standard error handling.
As the Strategic Missions Division scaled, multiple teams needed to test against the same hardware APIs without blocking each other or requiring dedicated hardware allocations.
Constraints
- •Must match production hardware API behavior exactly
- •Integrate with existing Jenkins CI/CD pipeline (no infrastructure changes)
- •Support parallel test execution for multiple teams
- •Zero downtime during simulator updates
- •Must be maintainable by engineers unfamiliar with original codebase
Solution
Transformed the prototype into a production-grade framework with standardized interfaces, Docker containerization, and comprehensive documentation.
Architecture
Technical Highlights
1. Standardized HTTP Status Codes
Fixed critical bugs where the simulator returned inconsistent status codes. Implemented a standard error-handling middleware.
# Before: inconsistent error handling
def endpoint():
if error:
return {"error": "bad"}, 500 # Sometimes 400, 500, 200...
# After: standardized responses
class APIResponse:
@staticmethod
def success(data): return jsonify(data), 200
@staticmethod
def bad_request(msg): return jsonify({"error": msg}), 400
@staticmethod
def not_found(msg): return jsonify({"error": msg}), 4042. Docker Containerization
Packaged the simulator as a Docker container for consistent deployment across developer machines, CI/CD, and test environments.
FROM python:3.9-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
EXPOSE 5000
CMD ["python", "simulator.py"]3. State Machine for Hardware Behavior
Implemented a state machine to accurately model hardware behavior (initialization sequences, error conditions, state transitions).
class HardwareState(Enum):
IDLE = "idle"
INITIALIZING = "initializing"
READY = "ready"
ERROR = "error"
class HardwareSimulator:
def __init__(self):
self.state = HardwareState.IDLE
def initialize(self):
if self.state != HardwareState.IDLE:
raise InvalidStateError()
self.state = HardwareState.INITIALIZING
# Simulate initialization delay
time.sleep(2)
self.state = HardwareState.READY4. Jenkins CI/CD Integration
Integrated with existing Jenkins pipeline using docker-compose. Tests now run automatically on every commit without requiring hardware.
# Jenkinsfile (simplified)
pipeline {
stages {
stage('Test') {
steps {
sh 'docker-compose up -d simulator'
sh 'pytest tests/ --simulator=docker'
sh 'docker-compose down'
}
}
}
}5. Documentation & Adoption Strategy
Wrote comprehensive documentation, example test cases, and migration guides. Presented at team demos to drive adoption across the division.
Results
- •Scaled from 7-person team tool to framework used by 50+ engineers
- •Reduced test cycle time from hours (with hardware) to minutes (with simulator)
- •Enabled parallel testing across multiple teams without hardware contention
- •Fixed critical API bugs standardizing HTTP status codes across CI/CD pipeline
- •Early adopter of company's VSCode AI tool—documented use cases that informed enterprise rollout
What I'd Do Next
- •Add support for simulating hardware failures and edge cases
- •Implement request recording/replay for creating test fixtures from production traffic
- •Build a web UI for inspecting simulator state and logs
- •Add performance benchmarking to catch API performance regressions
- •Containerize with Kubernetes for multi-tenant simulator deployments