Suita care a strigat 'Lupuuul!'

TL;DR:

• O suită în care nimeni nu mai are încredere e o problemă de credibilitate, nu de tooling.
• Migrarea către un framework nou rareori rezolvă asta. De obicei doar mută haosul într-un loc mai nou.
• Trei suspecți obișnuiți: wait-uri instabile, state partajat și teste care verifică prea multe lucruri deodată.
• Ca să găsești cauza reală, urmărește click-ul: află exact ce cod de frontend și backend rulează și în ce ordine.
• Încrederea se recâștigă în modul plicticos: un run verde onest, pe rând. Și eu sunt încă pe drumul ăsta.

Luni dimineață, când nimeni nu mai crede în build-ul roșu

Fiecare echipă din care am făcut parte a avut unul. Un pipeline care devine roșu, și în loc ca cineva să se uite la el, pur și simplu îl rulează din nou.

O să fiu sinceră: am fost și eu acel cineva. De mai multe ori decât pot număra. Nu din lene, ci pentru că experiența mă învățase că roșul probabil minte. Încă mă surprind, din când în când, apăsând butonul de rerun. Doar că mult, mult mai rar decât înainte.

Acela e momentul în care o suită nu mai e o plasă de siguranță, ci devine zgomot de fundal. Nimeni nu mai deschide raportul. Nimeni nu mai blochează un release din cauza lui. Rulează, cuminte, la fiecare build. Doar că nu mai e crezut.

Ma gândesc mult la asta în timp ce lucrez la framework-ul de automatizare pentru applicatie desktop despre care scriu în această serie. Înainte să scriu o singură asertare, vreau să știu: când testul acesta va pica peste șase luni, va avea cineva încredere în ce îi spune? Cel putin asta, daca tot e mai complicat de a-l stabiliza.

Să schimbi tool-ul mută mobila, nu și haosul

Instinctul, când o suită strigă lupul prea des, e să dai vina pe tool. „Selenium e instabil, trecem pe Playwright.” „WinAppDriver nu e de încredere, încercăm altceva mai nou.” Câteodată e chiar adevărat. De cele mai multe ori, e un mod foarte costisitor de a evita o discuție mai mică și mai puțin palpitantă.

Am fost în echipe care au petrecut un trimestru migrând framework-uri și am ajuns, aproape exact, înapoi de unde am pornit: o suită verde în zilele bune și misterios roșie în cele rele, doar scrisă acum în altă sintaxă.

Un tool nou nu rezolvă de ce a pierdut suita credibilitatea. Doar le dă aceleași probleme o haină nouă, și câteva luni liniștite înainte să ne reamintim cu toții de ce nu mai aveam încredere în ea.

Suspecții obișnuiți

Înainte să te apuci de framework, caută acești trei, pentru că, din experiența mea, aproape mereu unul dintre ei e vinovatul:

• Wait-uri instabile. Sleep-uri hardcodate, pattern-uri de „așteaptă și speră”, sau așteptarea semnalului greșit. Testul nu e greșit, e doar nerăbdător.
• State partajat. Teste care trec doar într-o anumită ordine, sau care depind, pe tăcute, de date lăsate de alt test. Rulate singure, pică. Rulate cu toată suita, „merg”.
• Teste care verifică prea multe lucruri. Un singur test care bifează cinci lucruri fără legătură. Când pică, nimeni nu știe care dintre cele cinci s-a stricat, așa că eșecul e catalogat drept „probabil nimic”.

Fiecare dintre acestea produce exact același simptom: un rezultat roșu care nu înseamnă ce spune. Și după ce se întâmplă de câteva ori, nu mai citim deloc mesajul.

Nici Google nu a scăpat de asta. În 2016, acum zece ani, raportau că aproximativ 84% dintre tranzițiile de la pass la fail din corpusul lor de teste implicau un test flaky (Flaky Tests at Google and How We Mitigate Them, Google Testing Blog). Cifra e veche. Problema, evident, nu: un deceniu de tool-uri noi mai târziu, purtăm cu toții aceeași discuție.

Un test care pică din motivul greșit face adesea mai mult rău decât un bug care nu a fost prins deloc.

Urmărește click-ul până la capăt

Să identifici suspectul e doar jumătate din treabă. Ca să-l dovedești, trebuie să înțelegi ce exercită de fapt testul, nu doar pe ce dă click.

Ia un test de UI care dă click pe un buton „Save” și uneori pică. Înainte să ating testul, vreau să știu ce se întâmplă în culise:

• Ce funcție din frontend declanșează click-ul?
• Apelează backend-ul o singură dată sau pornește un lanț: un request de validare, apoi salvarea, apoi un refresh al listei?
• În ce ordine au loc aceste apeluri și așteaptă UI-ul după toate, sau doar după primul?
• Ce face backend-ul cu request-ul: scrie într-o bază de date, pune un mesaj într-o coadă, apelează alt serviciu?

Odată ce poți desena lanțul ăsta, flakiness-ul de obicei nu mai e un mister. Testul așteaptă ca butonul să redevină activ, dar lista se reîncarcă dintr-un al doilea apel, mai lent. Sau backend-ul salvează asincron, iar pasul următor citește date care încă nu există. Testul nu greșește la întâmplare. Verifică într-un moment în care aplicația nu a promis niciodată că e gata.

Așa că citește handler-ul din frontend, aruncă o privire pe endpoint-ul din backend, deschide tab-ul de network, întreabă developerul care l-a scris. Pare mai lent decât să mai adaugi un wait. E singurul lucru care chiar restrânge cauza.

Reconstruirea încrederii, un run plicticos pe rând

Nu există shortcut aici, și aș minți dacă aș spune altceva. Încrederea revine pe drumul lent: un test pică, cineva investighează, și eșecul se confirmă real. Repetă asta de suficiente ori și echipa, inclusiv eu, începe din nou să se uite la build-urile roșii, în loc să le reruleze din reflex.

Ăsta e, de fapt, standardul pentru framework-ul la care lucrez acum. Nu „rulează rapid”, nu „arată modern”. Doar: când spune că s-a stricat ceva, spune adevărul?

Dacă suita ta nu trece încă de acest standard, un tool nou nu te va duce acolo. Un diagnostic, da.

Și o mărturisire, pentru că acesta e un jurnal: nici suita mea nu trece încă de standardul ăsta. Am câteva teste care stau pe lista „de refăcut” de mai mult timp decât mi-ar plăcea să recunosc, și nu sunt mândră de asta. Dar lucrez la ele chiar acum, cu pași mici, un test pe rând: urmăresc click-ul, repar cauza, trec la următorul.

Așa că, dacă ai și tu o listă ca asta, consideră asta o invitație: alătură-te mie în lupta cu testele flaky. Alege unul săptămâna asta. Doar unul.

În episodul următor: odată ce suita e din nou onestă, următoarea întrebare e unde ar trebui să trăiască de fapt fiecare test. Acela e Episodul 3.