Test: Implement Integration: WebSocket Live Driver Location Updates

[AdaBebe0]

Closes #474

Re-opening this work — the original branch was deleted by mistake, so this is a fresh branch with the same scope.

What the issue asks for

Mock WebSocket events emitting driver coordinates and ensure the UI map state updates accordingly.

What I found first

There was no path from a socket event to the fleet map. useFleet fetches a driver snapshot over REST and FleetMapClient renders it, but nothing folded live telemetry back into that list — DRIVER_LOCATION (or any equivalent) appears nowhere in the repo. So there was no seam to write an integration test against.

This PR adds that seam as a thin hook, then tests it end to end. Flagging it explicitly since the issue is labelled testing and I'd rather not slip production code in unannounced — happy to split the hook into its own PR if the team prefers.

Changes

hooks/useDriverLocations.ts — subscribes to DRIVER_LOCATION while the socket is connected and overlays incoming coordinates onto the driver list. Follows the existing layering (Component → Hook → socketService), same shape as useLiveUpdates. Three deliberate behaviours:

• events for an unknown driverId are ignored rather than inventing a marker
• malformed frames (missing id, NaN coordinates) are dropped, so a marker can never jump to NaN,NaN
• an older frame does not overwrite a newer one — out-of-order delivery is normal on reconnect

__tests__/integration/DriverLocationUpdates.test.tsx — 9 tests:

Group	Covers
Subscription lifecycle	subscribes when connected; does not subscribe when disconnected; unsubscribes on unmount
Map state updates	one frame moves the marker; a sequence tracks one driver; only the named driver moves
Resilience	unknown driver ignored; malformed frame ignored; out-of-order frame ignored

Test approach

The socket is mocked at the service boundary, so no real connection is opened. Leaflet is stubbed wholesale — jsdom has no layout engine, so the real MapContainer cannot mount — following the pattern already established in components/fleet/__tests__/FleetMapClient.test.tsx. The stubs expose marker centres as data attributes, so assertions read against what a fleet manager would actually see move on the map, not against hook internals.

Verification

• 9/9 passing
• pnpm run lint — no new errors
• tsc --noEmit — no errors in either new file
• Mutation-checked: removing the hook's merge step fails 4 of the 9 tests, confirming they aren't passing vacuously

Note on CI

CI on this repo is currently red on main for every PR — pnpm run lint exits 1 on 4 pre-existing errors, so Type Check and Test never run. #542 fixes that, and #543 clears 110 of the pre-existing type errors. Neither is related to this PR, but this PR's checks won't go green until #542 lands.

[drips-wave]

@AdaBebe0 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits