Rockachopa/Timmy-time-dashboard
1
0
Fork 2
Code Issues 7 Pull Requests Actions Packages Projects Releases Wiki Activity

[loop-generated] [test] Add unit tests for infrastructure/hermes/monitor.py — 660 lines untested #1371

New Issue
Closed
opened 2026-03-24 10:08:59 +00:00 by Timmy · 1 comment
Timmy commented 2026-03-24 10:08:59 +00:00
Owner
Copy Link

Priority: High
Impact: System reliability, test coverage
Size: 660 lines, 0% test coverage

Problem

src/infrastructure/hermes/monitor.py has NO unit test coverage despite being 660 lines of critical system monitoring code. This is a major reliability risk.

Required Test Coverage

  1. Memory monitoring: Test memory pressure detection, threshold checks
  2. Disk monitoring: Test disk usage calculation, cleanup triggers
  3. Ollama monitoring: Test service status checks, model management
  4. Process monitoring: Test zombie detection, health checks
  5. Network monitoring: Test connectivity validation
  6. Alert system: Test alert triggering, rate limiting
  7. Error handling: Test failure scenarios, graceful degradation

Test File

tests/infrastructure/test_hermes_monitor.py

Acceptance Criteria

  • Create comprehensive test suite
  • Mock external dependencies (disk, network, processes)
  • Test both success and failure scenarios
  • Achieve >85% code coverage
  • Include integration tests for critical paths
  • Verify alert behavior under various conditions

Testing Strategy

  • Use pytest fixtures for mocking system calls
  • Test threshold-based alerting
  • Verify cleanup operations work correctly
  • Test configuration edge cases

Estimated effort: 4-5 hours

**Priority**: High **Impact**: System reliability, test coverage **Size**: 660 lines, 0% test coverage ## Problem `src/infrastructure/hermes/monitor.py` has NO unit test coverage despite being 660 lines of critical system monitoring code. This is a major reliability risk. ## Required Test Coverage 1. **Memory monitoring**: Test memory pressure detection, threshold checks 2. **Disk monitoring**: Test disk usage calculation, cleanup triggers 3. **Ollama monitoring**: Test service status checks, model management 4. **Process monitoring**: Test zombie detection, health checks 5. **Network monitoring**: Test connectivity validation 6. **Alert system**: Test alert triggering, rate limiting 7. **Error handling**: Test failure scenarios, graceful degradation ## Test File `tests/infrastructure/test_hermes_monitor.py` ## Acceptance Criteria - [ ] Create comprehensive test suite - [ ] Mock external dependencies (disk, network, processes) - [ ] Test both success and failure scenarios - [ ] Achieve >85% code coverage - [ ] Include integration tests for critical paths - [ ] Verify alert behavior under various conditions ## Testing Strategy - Use pytest fixtures for mocking system calls - Test threshold-based alerting - Verify cleanup operations work correctly - Test configuration edge cases Estimated effort: 4-5 hours
Timmy commented 2026-03-24 10:21:12 +00:00
Author
Owner
Copy Link

Kimi Task Instructions

Files to work with:

  • src/infrastructure/hermes/monitor.py (read-only, analyze code structure)
  • tests/infrastructure/test_hermes_monitor.py (create this new test file)

What to implement:

  1. Create comprehensive unit tests for the SystemMonitor class and all its methods
  2. Focus on these critical methods:
    • check_memory_pressure() - mock system stats, test thresholds
    • check_disk_usage() - mock disk stats, test percentage calculations
    • check_ollama_status() - mock HTTP responses, test connectivity
    • get_process_health() - mock process info, test health scoring
    • generate_status_report() - test report formatting and completeness

Test structure to follow:

import pytest
from unittest.mock import Mock, patch, MagicMock
from src.infrastructure.hermes.monitor import SystemMonitor, MemoryPressure, DiskUsage

class TestSystemMonitor:
    def test_check_memory_pressure_normal(self):
        # Mock psutil.virtual_memory() with normal values
        pass
    
    def test_check_memory_pressure_high(self):
        # Mock psutil.virtual_memory() with high usage
        pass
    
    # ... more tests

How to verify:
Run tox -e unit and ensure all new tests pass. Target 90%+ coverage of monitor.py.

Key testing principles:

  • Mock all external dependencies (psutil, requests, subprocess)
  • Test both normal and edge cases (high memory, disk full, ollama down)
  • Test error handling and graceful degradation
  • Ensure thread safety if applicable

This is critical system reliability code - thorough tests are essential.

## Kimi Task Instructions **Files to work with:** - `src/infrastructure/hermes/monitor.py` (read-only, analyze code structure) - `tests/infrastructure/test_hermes_monitor.py` (create this new test file) **What to implement:** 1. Create comprehensive unit tests for the `SystemMonitor` class and all its methods 2. Focus on these critical methods: - `check_memory_pressure()` - mock system stats, test thresholds - `check_disk_usage()` - mock disk stats, test percentage calculations - `check_ollama_status()` - mock HTTP responses, test connectivity - `get_process_health()` - mock process info, test health scoring - `generate_status_report()` - test report formatting and completeness **Test structure to follow:** ```python import pytest from unittest.mock import Mock, patch, MagicMock from src.infrastructure.hermes.monitor import SystemMonitor, MemoryPressure, DiskUsage class TestSystemMonitor: def test_check_memory_pressure_normal(self): # Mock psutil.virtual_memory() with normal values pass def test_check_memory_pressure_high(self): # Mock psutil.virtual_memory() with high usage pass # ... more tests ``` **How to verify:** Run `tox -e unit` and ensure all new tests pass. Target 90%+ coverage of monitor.py. **Key testing principles:** - Mock all external dependencies (psutil, requests, subprocess) - Test both normal and edge cases (high memory, disk full, ollama down) - Test error handling and graceful degradation - Ensure thread safety if applicable This is critical system reliability code - thorough tests are essential.
kimi was assigned by Timmy 2026-03-24 10:21:12 +00:00
kimi was unassigned by Timmy 2026-03-24 19:33:37 +00:00
Timmy closed this issue 2026-03-24 21:54:35 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
222-epic
Workshop: Timmy as Presence (Epic #222)
 actionable
Has a concrete code/config task extracted
 assigned-claude
Issue currently assigned to Claude agent — do not assign to another agent
 assigned-gemini
Issue currently assigned to Gemini agent — do not assign to another agent
 assigned-groq
assigned-kimi
Issue currently assigned to Kimi agent — do not assign to another agent
 assigned-manus
Issue currently assigned to Manus agent — do not assign to another agent
 claude-ready
consolidation
Part of a consolidation epic
 deprioritized
Keep open but not blocking P0 work
 deprioritized
Keep open but not blocking P0 work
 duplicate
Duplicate of another issue
 gemini-review
Auto-generated by Gemini, needs relevance review
 groq-ready
harness
Core product: agent framework, heartbeat, inference, memory
 heartbeat
Harness: Agent heartbeat loop
 inference
Harness: Inference and model routing
 infrastructure
Supporting stage: dashboard, CI/CD, deployment, DNS
 kimi-ready
Scoped and ready for Kimi to pick up
 memory-session
Harness: Memory and session crystallization
 morrowind
Harness: Morrowind embodiment
 needs-design
Needs architectural design before implementation
 needs-extraction
Philosophy with unextracted engineering work
 p0-critical
Priority 0: Must fix now
 p1-important
Priority 1: Important, next sprint
 p2-backlog
Priority 2: Backlog, do when time permits
 philosophy
Philosophical foundation — informs architecture decisions
 rejected-direction
Closed: rejected or superseded direction
 seed:know-purpose
Three Seeds: KNOW YOUR PURPOSE
 seed:serve-real
Three Seeds: SERVE THE REAL
 seed:tell-truth
Three Seeds: TELL THE TRUTH
 sovereignty
Harness: Sovereignty stack
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Timmy claude grok groq kimi manus perplexity Rockachopa
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Rockachopa/Timmy-time-dashboard#1371
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?