tfm_ainventory/.planning/TESTING_PLAN.md

Phase 6 Standalone Deployment - Comprehensive Testing Plan

Scope of Changes

Frontend (4 files):

• ✅ Toast.tsx (new component)
• ⚠️ db.ts (id type - FIXED)
• ⚠️ SearchModal.tsx (type change)
• ⚠️ QuantityAdjustmentModal.tsx (type change)

Backend (1 file):

• ⚠️ requirements.txt (openpyxl version)

Config & Deployment (3 files):

• ✅ inventory.env (added DATA_DIR, LOGS_DIR, LOG_LEVEL)
• ✅ start_servers.py (new Python launcher)
• ✅ Caddyfile.standalone (new reverse proxy config)

Documentation (1 file):

• ✅ STANDALONE_DEPLOYMENT.md

---

Testing Plan

Phase 1: Backend Functionality Tests (CRITICAL)

Why: Backend may be broken by openpyxl version change

Tests to run:

1. ✅ Delete Item (was broken, now fixed - MUST VERIFY)

   • Create item in inventory
   • Click delete
   • Confirm deletion works
   • Verify item gone from UI and database

2. ✅ Export Snapshot (uses openpyxl)

   • Go to Admin panel
   • Click "Export Snapshot"
   • Verify Excel file downloads
   • Open Excel file - verify data intact

3. ✅ Export Audit Trail (uses openpyxl)

   • Go to Admin panel
   • Click "Export Audit Trail"
   • Verify Excel file downloads with all columns

4. ✅ Search Items (SearchModal type changed)

   • Press Ctrl+K to search
   • Search for an item
   • Click result to select
   • Verify item loads correctly

5. ✅ Quantity Adjustment (type changed)

   • Select item from list
   • Adjust quantity with +/- buttons
   • Save changes
   • Verify quantity updated

Phase 2: Frontend UI Tests (HIGH)

Why: Toast component is new, type changes affect components

Tests to run:

1. ✅ Toast Notifications

   • Perform any successful action (add/edit/delete)
   • Verify success toast appears
   • Verify it auto-dismisses after 3 seconds

2. ✅ Error Messages

   • Try delete without confirmation
   • Perform operation that fails
   • Verify error toast appears

3. ✅ All CRUD Operations

   • Create new item
   • Edit item details
   • Update category
   • Delete item
   • Verify all work without errors in console

Phase 3: Deployment Tests (CRITICAL)

Why: New deployment mode must work reliably

Tests to run:

3.1 Standalone Foreground Mode

python3 start_servers.py

• ✅ All 3 services start (backend, frontend, caddy)
• ✅ No errors in console
• ✅ All log files created (backend.log, frontend.log, caddy.log)
• ✅ Access http://localhost:8916 (backend)
• ✅ Access http://localhost:8917 (frontend)
• ✅ Access https://localhost:8918 (backend SSL)
• ✅ Access https://localhost:8919 (frontend SSL)
• ✅ Browser accepts self-signed certificate
• ✅ Ctrl+C stops all services cleanly

3.2 Standalone Background Mode

python3 start_servers.py start

• ✅ Services start in background
• ✅ PID file created (.servers.pid)
• ✅ Can access services immediately
• ✅ No terminal output after start

3.3 Status Command

python3 start_servers.py status

• ✅ Shows all 3 services running
• ✅ Shows correct PIDs
• ✅ Shows correct ports (HTTP and HTTPS)
• ✅ Shows correct log file paths

3.4 Stop Command

python3 start_servers.py stop

• ✅ All services terminate gracefully
• ✅ PID file removed
• ✅ Ports release (netstat shows ports free)

3.5 Restart Command

python3 start_servers.py restart

• ✅ Services stop then start
• ✅ New PIDs assigned
• ✅ All services responsive immediately

Phase 4: Network/SSL Tests (HIGH)

Why: Caddy proxy added complexity

Tests to run:

1. ✅ Access via localhost

   • http://localhost:8916 (backend)
   • http://localhost:8917 (frontend)
   • https://localhost:8918 (backend SSL)
   • https://localhost:8919 (frontend SSL)

2. ✅ Access via IP address

   • http://192.168.84.131:8916
   • http://192.168.84.131:8917
   • https://192.168.84.131:8918 (self-signed warning - accept)
   • https://192.168.84.131:8919 (self-signed warning - accept)

3. ✅ HTTPS Certificate

   • Certificate generates on first HTTPS access
   • Certificate is self-signed (ok for dev)
   • No errors accessing multiple times

4. ✅ Proxy Headers

   • Application receives correct X-Forwarded headers
   • Frontend renders correctly with forwarded proto/host

Phase 5: Data Persistence Tests (MEDIUM)

Why: Changed paths for data/logs directories

Tests to run:

1. ✅ Data Directory

   • Data saved to ./data/ directory
   • Database file created at ./data/inventory.db
   • Data persists across restarts

2. ✅ Logs Directory

   • Logs written to ./logs/ directory
   • Separate log files for backend, frontend, caddy
   • Logs don't grow unbounded

---

Test Execution Schedule

Priority 1 (MUST PASS):

• Phase 1: Delete Item
• Phase 1: Export operations
• Phase 3: All deployment modes
• Phase 4: SSL access via IP

Priority 2 (SHOULD PASS):

• Phase 1: Search & Quantity Adjustment
• Phase 2: Toast notifications
• Phase 4: HTTPS certificate

Priority 3 (NICE TO HAVE):

• Phase 2: Full CRUD
• Phase 5: Data persistence

---

Success Criteria

✅ PASS if:

• All Phase 1 tests pass (backend functionality)
• All Phase 3 tests pass (deployment modes)
• All Phase 4 tests pass (SSL/network)
• No new errors in browser console
• No uncaught exceptions in logs

❌ FAIL if:

• Any CRUD operation fails
• Deployment modes don't start/stop cleanly
• SSL certificates fail to generate
• Static assets (CSS/JS) don't load
• Database operations fail

---

Approval Requested

Should I execute this testing plan?

• Yes, run all tests
• Yes, run Priority 1 only
• No, modify plan first

---

Generated: 2026-04-22 Scope: All Phase 6 changes Estimated time: 30-45 minutes for full test