Testing Guide

RUSEON Core adheres to strict quality and reliability standards. The repository contains over 35 test suites covering unit logic, concurrent data structures, end-to-end media transmuxing pipelines, chaos simulations, and high-load benchmarks.

Test Suites Overview

Category	Target Packages / Files	Purpose
Unit Tests	internal/api/*_test.go, internal/db/*_test.go	Route handlers, auth middleware, BadgerDB transactions
Concurrency & Race Tests	internal/buffer/*_test.go, internal/stream/*_test.go	Detecting data races and deadlocks under -race flag
Go Native Fuzzing	internal/buffer/fuzz_test.go	RingBuffer boundary safety, ring wrapping, and arbitrary payload testing
Chaos & Resilience	internal/recorder/chaos_test.go, internal/stream/chaos_test.go	Simulating unexpected RTSP drops, disk latency, and partial writes
Testcontainers E2E	tests/e2e/ingest_test.go, internal/api/e2e_race_test.go	Full media flow validation with real MediaMTX & FFmpeg Docker containers
High-Load Benchmarks	internal/stream/hls_bench_test.go, internal/buffer/ring_bench_test.go	Measuring zero-allocation invariants, throughput, and CPU allocations

---

1. Running Unit & Race Detection Tests

Always run tests with the Go race detector enabled:

# Run all unit tests with race detection and coverage
go test -v -race -timeout=10m -coverprofile=coverage.out ./...

# View coverage summary per package
go tool cover -func=coverage.out

To view HTML coverage in your browser:

go tool cover -html=coverage.out -o coverage.html

---

2. Go Native Fuzz Testing

The Lock-Free RingBuffer (internal/buffer) uses Go native fuzzing to stress-test concurrent reader/writer boundaries against corrupt or malicious inputs:

# Run fuzz tests for 60 seconds
go test -v -fuzz=FuzzRingBuffer -fuzztime=60s ./internal/buffer

The fuzzer verifies that:

• Head/tail index wrapping never panics on uint64 overflows.
• Subscriber channels are not blocked by slow readers.
• Memory allocation counters remain zero during active frame dispatch.

---

3. Testcontainers End-to-End (E2E) Pipeline

The E2E test suite (tests/e2e/ingest_test.go) spins up an isolated Docker bridge network containing:

1. MediaMTX 1.19.2 as an RTSP server.
2. FFmpeg 8-alpine generating a synthetic H.264 video pattern (10 fps, GOP = 10).
3. RUSEON Core Server ingesting RTSP, publishing to RingBuffer, and serving HLS/WebRTC.

Run the E2E tests (Docker daemon must be running):

go test -v -tags=e2e -timeout=15m ./tests/e2e/...

The test validates that:

• RTSP ingest establishes TCP connection and reads SPS/PPS parameters.
• /livez and /readyz transition to healthy state.
• HLS Master Playlist (index.m3u8) and Media Playlist (stream.m3u8) are served.
• Generated MPEG-TS segments contain valid 0x47 sync bytes and playable video.

---

4. High-Load Benchmarking

Run CPU and memory allocation benchmarks:

# Execute benchmarks across all packages
go test -v -bench=. -benchmem -run=^$$ ./...

# Benchmark the Ring Buffer frame broadcaster specifically
go test -v -bench=BenchmarkRingBuffer_Broadcast -benchmem ./internal/buffer

Key Performance Thresholds:

• RingBuffer Dispatch: ~55 ns/op, 0 B/op, 0 allocs/op.
• HLS Master Playlist Delivery: < 0.5 ms latency under 5,000 concurrent requests.
• Direct I/O fMP4 Archiver: Constant memory footprint regardless of stream bitrate.

---

5. Frontend UI Component Tests

The React 19 web interface uses Vitest and React Testing Library:

cd web

# Run Vitest test suite
npm run test:unit

# Run type check and linting
npm run typecheck
npm run lint

Related Documentation

• Environment Setup
• CI/CD Workflows
• Architecture: Ring Buffer
• Performance Benchmarks