Basta con i teatrini: i test TanStack o li fai nel browser reale o stai solo perdendo tempo (e soldi).

Mezzanotte. La deadline è domani. E c'è un bug che non ha nessun senso.

Partiamo da un'immagine che conosciamo tutti. È tardi, hai gli occhi che bruciano per lo schermo e c'è un bug in produzione che appare e scompare come un fantasma. Sulla tua macchina, nei tuoi test unitari con `MemoryRouter` e un `QueryClient` nuovo di zecca per ogni scenario, tutto è verde. Un verde brillante, quasi beffardo. Hai scritto più codice per il setup dei test che per il componente stesso, un groviglio di provider e mock che farebbe impallidire un piatto di spaghetti. Eppure, l'applicazione live va a gambe all'aria. Il ROI di cui parlavi in riunione è diventato un miraggio e la tua notte un incubo a base di caffè e bestemmie a bassa voce. Ecco, questo è il costo, quello vero, del testing fatto "come si deve", secondo manuale. Un salasso silenzioso che qui a ThinkPink, tra la calma di Rosignano e il caos creativo di Kampala, abbiamo deciso di non pagare più.

Testare le Single Page Application moderne, soprattutto quelle che si appoggiano su pesi massimi della reattività come TanStack Query e TanStack Router, è un percorso a ostacoli. Le metodologie standard ci spingono a usare `jsdom`, che per quanto utile, resta una finzione. Una recita. E lo sappiamo tutti che in una recita i problemi veri non vengono mai a galla. Il risultato? Test che passano, clienti che si lamentano e un debito tecnico che lievita nel silenzio, mangiandosi tempo e margini.

Il grande inganno del testing nel 2026

Certo, le cifre dicono che il mercato del software testing è una bestia da 57 miliardi di dollari, destinata a sfiorare i 94 entro il 2030. Un sacco di soldi spesi per sentirsi sicuri. Peccato che sia una sicurezza fittizia. La realtà, quella che vediamo sul campo, è un'altra cosa. I report, quelli che nessuno legge fino in fondo, parlano di test end-to-end (E2E) che sono una lotteria: il 30-40% fallisce a caso, senza un motivo apparente. Sono lenti, fragili e la loro manutenzione è un lavoro a tempo pieno. Oltre il 50% del tempo dedicato al testing se ne va per aggiustare test che si rompono perché un designer ha cambiato una classe CSS. Un'assurdità.

Non sono piccoli fastidi. Sono costi operativi. È un freno a mano tirato mentre cerchi di accelerare. Più la tua applicazione è complessa, più i test, invece di essere un paracadute, diventano un'ancora che ti trascina a fondo. Un paradosso che ci è costato qualche notte di sonno di troppo.

Finché non abbiamo cambiato le regole del gioco.

TWD.js: Meno chiacchiere, più browser.

Il punto non è testare di più, è testare meglio. Smetterla di simulare e iniziare a verificare. Per questo da noi è entrato prepotentemente TWD.js. Non è l'ennesimo framework E2E pesante e complesso. È l'esatto contrario: è un sistema per eseguire i test *dentro* la tua applicazione, nel browser che usa il tuo utente. Contro il router vero, il query client vero, l'albero dei componenti vero. Niente più recite. Solo la cruda realtà.

L'installazione è quasi imbarazzante per quanto è semplice. Aggiungi due plugin a Vite e sei operativo. Il file di test non simula più nulla, vive nella stessa tab del browser in cui gira l'app. Accede a tutto. Le API sono le stesse di Testing Library, ma invece di puntare a un DOM finto, puntano al DOM vivo e vegeto. Scrivere i test diventa più semplice, logico. E soprattutto, più onesto.

Prendi la cache di TanStack Query. Nei test tradizionali, ogni test è una cella di isolamento. Nel mondo reale, la cache persiste. TWD.js lo sa, e ti espone il `QueryClient` come un singleton. Vuoi un test pulito? Basta una riga: `queryClient.clear()`. Sembra un dettaglio, ma è la differenza tra un test che ti dice la verità e uno che ti mente spudoratamente.

L'AI non è magia, è un martello pneumatico (se lo sai usare)

Il bello arriva quando abbini questo approccio alla realtà dell'Intelligenza Artificiale. Nel 2026, l'AI non è più un giocattolo per conferenze. È uno strumento di lavoro. I dati dicono che l'AI migliora l'affidabilità dei test del 33% e riduce i difetti del 29%. Ma i numeri da soli non bastano. Bisogna capire il perché. L'AI, abbinata a un sistema come TWD-relay, diventa un collega instancabile.

Immagina questo scenario: un agente AI scrive un file di test. Lancia `npx twd-relay run`. Il test parte nel browser. L'AI legge il risultato in console. Se fallisce, non apre un ticket. Analizza l'errore, corregge il test e lo fa ripartire. Tutto questo in pochi secondi, senza avviare simulatori, senza fare screenshot. Questa non è fantascienza. È il motivo per cui riusciamo a puntare a coperture del 90% senza dover assumere un esercito di persone. A Kampala, dove ottimizzare le risorse non è una scelta ma una necessità, questo approccio è diventato la normalità per garantire robustezza a software che devono funzionare in condizioni non sempre ideali. Non si tratta di sostituire i developer, ma di dar loro un martello pneumatico invece di un cucchiaino per abbattere un muro.

Gli strumenti di "self-healing", quelli che adattano i test quando la UI cambia, non sono più un lusso. Sono una necessità per non buttare via metà del tempo in manutenzione. L'Africa Innovation Summit 2026 che si terrà proprio a Kampala non a caso si concentra su questi temi: AI e trasformazione digitale non sono marketing, sono leve strategiche per la sopravvivenza.

Metodo Rosignano, grinta Kampala: la qualità che scala

La nostra filosofia nasce da due anime. Quella di Rosignano Solvay, dove le cose si fanno con metodo, precisione, senza fronzoli. E quella di Kampala, dove devi essere resiliente, ingegnoso, capace di trovare la soluzione migliore con quello che hai. Questo mix ci dà una prospettiva diversa sulla qualità del software.

Per una PMI italiana che vuole affacciarsi al mondo, la robustezza del software non è un optional. È il passaporto. Adottare strumenti come TWD.js e integrarli con processi di automazione intelligenti significa costruire una base che non solo funziona oggi, ma che non crollerà domani al primo cambiamento. Significa smettere di accumulare quel debito tecnico invisibile che prima o poi presenta il conto.

Il vero valore non è in quante feature sforni, ma in quante notti riesci a dormire senza l'ansia di una telefonata del cliente. Passare da test fragili e manuali a un sistema di verifica integrato e intelligente non è un upgrade tecnologico. È una decisione di business. Quelle che ti separano da chi arranca e chi, invece, corre.

La domanda non è "quanto costa", ma "quanto ti costa non farlo"

Chiariamo una cosa: l'automazione intelligente non è una spesa, è un investimento che si ripaga da solo. E in fretta. Le aziende che la implementano vedono un ROI medio del 312% in 18 mesi. Rilasciano software quasi il 50% più velocemente. Rilevano il 54% in più di bug prima che arrivino in produzione. Tradotto in soldoni: meno costi di supporto, meno figure dedicate al testing manuale, meno danni d'immagine.

Non stiamo parlando di una moda. Stiamo parlando di non ritrovarsi con un prodotto tecnicamente obsoleto tra un anno. Il testing deve avvenire prima, il più presto possibile nel ciclo di sviluppo. Bisogna trovare i problemi quando costano pochi euro per essere risolti, non quando costano migliaia di euro in danni e tempo perso.

La nostra missione in ThinkPink è questa. Aiutare le aziende a fare questo salto. Con strumenti come TWD.js e l'AI, offriamo un modo per rendere la qualità una certezza, non una speranza appesa a un test che passa per puro caso. È ora di smettere di pagare il prezzo nascosto di un testing inefficiente. Il sonno, francamente, non ha prezzo.