Test ripetibili per watchlist di trading live: tempo come dipendenza

Per rendere ripetibili i test di una watchlist live serve controllo: il test decide il tempo degli eventi, svuota i batch con un watermark esplicito, verifica la presenza come transizione di stato. Niente sleep arbitrari¹.

Una watchlist non misura consegna, misura presenza. L’utente guarda se AAPL è visibile ora, se un simbolo sparisce dopo un disconnect, se l’ultimo prezzo è più nuovo di quello a schermo. Un batch che arriva 40 millisecondi dopo non cambia l’esperienza. Un simbolo stantio che sopravvive a un reconnect la rovina¹.

Qui nascono i test fragili. Il batching introduce ritardi intenzionali e variabili. Un server può aspettare una finestra breve o un numero massimo di elementi. Senza un orologio controllato, il test rincorre tempi che non controlla. Il risultato sono falsi negativi che compaiono quando il carico varia.

C’è una trappola comune. Si prepara una prova rapida in un notebook con pochi eventi, poi si promuove tutto in un piccolo harness e infine nel CI. Le assunzioni di timing del notebook, se importate così come sono, collassano sotto carico. L’autore racconta un test che passava in locale e falliva in CI all’indice evento 3 quando il runner era occupato. Dentro c’erano uno sleep reale, l’uso dell’orologio di sistema e nessuna definizione di “presente”. Tre fonti indipendenti di rumore¹.

Prima regola: il tempo va iniettato. Il test fornisce timestamp espliciti agli eventi. Non legge il wall clock. Il flusso avanza quando il test decide, non quando la macchina ha tempo. La sequenza resta ripetibile, anche sotto carico variabile. Ogni confronto fra “ultimo” e “penultimo” evento usa lo stesso riferimento.

Seconda regola: i batch si svuotano con un watermark esplicito. Il test dichiara che fino a quel tempo non arriveranno altri eventi, quindi il sistema può emettere lotti completi. Il flush non dipende più da finestre temporali reali o da contatori che si riempiono a ritmi diversi. Si esercitano le stesse regole di batching usate in produzione, ma il test resta deterministico¹.

Terza regola: la presenza si verifica come transizione di stato. Si asserisce che un simbolo passa da assente a presente, o da presente ad assente, o che avanza a un prezzo più recente. Non si dormono millisecondi sperando che il sistema “abbia finito”. La definizione di “presente” entra nel contratto del test. Questo elimina ambiguità e rumore, e concentra l’attenzione su ciò che conta a schermo in quel momento¹.

Takeaway operativo. “Presente” significa che, dato un tempo fissato dal test, il simbolo cambia stato secondo attesa entro quel tempo. Esempio essenziale: invia un evento per AAPL con timestamp t1, poi un aggiornamento con timestamp t2, quindi un watermark a t2. A quel punto asserisci che AAPL risulta presente e che l’ultimo dato è più recente del precedente. Per assenza, invia un evento di rimozione, poi un watermark, quindi asserisci che AAPL risulta assente. Niente sleep, solo tempi sotto controllo e una definizione chiara di stato. Questa è la differenza tra un test che passa a giorni alterni e un test che regge il CI¹.