Skip to content

TESTING.md

Latest commit

 

History

History
75 lines (52 loc) · 6.8 KB

TESTING.md

File metadata and controls

75 lines (52 loc) · 6.8 KB
Raw

Manual verification

Run these on the Mac and macOS version you intend to protect. Automated tests cover service coordination, not privacy dialogs, hardware latency, loudness, or lock-screen delivery. Perform audible tests somewhere a sudden loud alarm is appropriate. Use the built app bundle from a stable path.

Setup and lifetime

  1. Launch Tripwire. Confirm a shield in the menu bar, no Dock icon, and no normal main window.
  2. Without camera/input grants, confirm the permission setup is visible and arming cannot succeed. Grant them through macOS; reopen as requested.
  3. Start arming. Confirm camera privacy indicator, then a full five-second countdown. Cancel once from the menu and once with ⌃⌥⌘T; confirm the camera turns off and protection stays disarmed.
  4. Close any camera shutter, or make the camera unavailable, then try arming. Confirm a visible failure instead of an armed indicator.
  5. Arm and close the menu. Wait for the filled shield; confirm the process continues without the menu open.
  6. While armed, pmset -g assertions should list Tripwire's PreventUserIdleSystemSleep assertion. After disarm it should be absent. This is a read-only check.

Trigger and evidence

For each row, begin with a new armed session. Authenticate to stop the alarm between sessions.

Action Expected
Press a key or modifier Keyboard trigger, immediate siren, up to three JPEGs
Move pointer, click, drag, or scroll Mouse/trackpad trigger
Unplug an attached charger Charger-disconnected trigger
Arm while already on battery No trigger merely for being on battery
Let display sleep, then wake it Display-wake or earlier input trigger
Put armed Mac to sleep and wake it Armed state survives sleep; system/display wake triggers on resume
Close lid, then reopen it Wake coverage if macOS reports it; no guarantee of capture while closed
Change hinge angle by about 10° while Mac remains awake Lid-movement trigger when the sensor was ready at arm time
Gently lift/tilt the laptop without touching input devices Physical-movement trigger when the sensor was ready at arm time
Rapidly cause several signals One event and one photo burst, no overlapping alarms
Revoke input permission while armed Monitor failure trigger if macOS keeps the process running and reports the loss

The first observed signal wins, so moving the pointer before a power test can correctly record pointer activity instead of power removal.

Open Events. Confirm event.json exists even if the camera failed, UTC timestamps and reason are accurate, and each recorded filename exists. Check that the photographs are decodable and separated in time. Verify incomplete/failed capture diagnostics if the camera is unavailable. Confirm no photos were saved during an untriggered armed session.

Authentication and audio

  1. Use Test sound… and accept its confirmation. Confirm two seconds of loud sound from the Mac's built-in speakers, including with Bluetooth headphones selected as the global output. Confirm prior speaker volume/mute restoration.
  2. Trigger a real event. Open disarm, cancel authentication, and confirm the siren continues. Repeat with Touch ID or the Mac password and confirm it stops, the camera stops, and disarmedAt is saved.
  3. Try ordinary Quit while armed and while triggered. Confirm it requires successful disarm. Force quit is explicitly outside this protection.
  4. Try disarming with the shortcut. Interaction may trigger first; there must be no shortcut that bypasses authentication.
  5. Verify failure messages when the output has no adjustable gain or cannot be routed. Hardware audio failure must not prevent camera/event recording.

Known weak conditions

Repeat selected checks with the screen locked, Secure Input enabled, the lid closed, an external display, a busy camera, and system sleep. Record the actual macOS version, hardware, and outcomes. Missing keyboard events or camera frames in these states are platform limits to disclose, not reasons to add unsupported APIs. Do not treat a single successful lock-screen capture as a cross-version guarantee.

Silent hinge and movement check

This does not need Camera or Input Monitoring permission. It plays no sound and saves no photos.

  1. While disarmed, click Check under hardware sensors. Keep the Mac on a stable surface for three seconds. Both sensors should show Ready if accessible; note any unavailable message.
  2. Gently change the hinge angle by approximately 10° without closing the lid. Expect Detected: Lid angle changed.
  3. Gently lift and tilt the Mac a little, keeping hands off the trackpad/keyboard. Expect Detected: Mac moved or tilted. A hinge action may also move the chassis and produce both signals.
  4. Click Stop check, or let it finish after 60 seconds. Arming is disabled during the check. Check again to verify cleanup/restart. Readings retained afterward are the last test result.
  5. Repeat with the Mac untouched for the full minute to check for spurious detections on your surface. Café table bumps may genuinely trigger the motion threshold.

Developers can run the same adapter from a terminal, with a bounded duration (5–300 seconds):

export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer
swift run TripwireSensorProbe 30

Do not run this while Tripwire or another SPU tool is monitoring hardware: driver settings are shared across processes. Let it finish normally to restore those settings. The CLI prints live angles, acceleration, sample counts, and detections. Never run it with sudo to hide an unsupported/permission-denied result.

On a Mac with no accessible SPU sensors, verify clear unavailable statuses and continued input/power/wake arming. If readings stop after becoming available, verify a monitoring-failure event (or cancelled arming), not stale green coverage. Unit tests exercise freshness, but inducing an actual driver failure safely is hardware-specific.

Automated checks

swift test exercises report lengths/identifiers/ranges, signed axis decoding, stationary calibration, fixed baselines, hinge direction and slow changes, tilt/lift thresholds, jitter/spikes, time gaps, stream loss/recovery, and JSON reasons. State-machine tests include all hardware reasons, five-second baseline freezing, failed calibration cleanup, authentication, cancellation, capture/storage failure, and duplicate suppression. No hardware is opened by unit tests.

Build verification in the initial development environment

This document lists procedures; it does not claim hardware checks were completed. The repository's initial handoff reports which automated/build/UI checks actually ran. Permission grants, siren loudness, camera photos, physical charger removal, lid closure, Touch ID/password, and sleeping/locking the user's active Mac require an attended acceptance pass.