Testele pentru expirare au nevoie de ceas și sincronizare

Un test de anulare ar trebui să stabilească dacă funcția de răspuns a avut ocazia să ruleze înainte să decidă că anularea a funcționat. O pauză arbitrară lasă această ocazie la voia încărcării mașinii. Ideea utilă din experimentul synctest al limbajului Go a fost controlul timpului și al progresului concurent observabil. Pentru regulile de expirare, acesta este un punct de plecare mai bun decât mărirea repetată a pauzei până când testul trece de obicei.

Privind din noiembrie 2026, limita istorică trebuie păstrată. Go 1.24 a fost lansat la 11 februarie 2025. Explicația despre testing/synctest din 19 februarie descria un experiment activat prin GOEXPERIMENT=synctest, în afara promisiunii de compatibilitate. Interfața folosea Run și Wait. Articolul discută experimentul din februarie, nu contractul unei interfețe stabile ulterioare.

Timpul scurs nu dovedește progresul

Să presupunem că un test propus anulează o operație, așteaptă puțin și verifică o variabilă de stare. Dacă variabila nu s-a schimbat, rămân două explicații. Anularea poate fi defectă sau funcția de răspuns poate să nu fi rulat încă. O pauză mai lungă face a doua explicație mai puțin probabilă pe unele mașini, dar prelungește fiecare execuție reușită. Pauza nu exprimă ordinea de care are nevoie verificarea.

Testarea condiției inverse întâmpină aceeași problemă. Faptul că ați așteptat și nu s-a întâmplat nimic nu dovedește, în general, că nimic nu era pregătit să se întâmple. Testul are nevoie de un punct definit în care operațiile relevante fie s-au încheiat, fie nu mai pot continua până la următoarea acțiune deliberată. Stabilirea acelui punct transformă o observație nesigură într-o afirmație despre o stare precisă a sistemului.

În proiectarea din februarie, funcția transmisă către Run și operațiile de tip goroutine pornite de aceasta se aflau într-un mediu izolat, numit bubble. Un ceas simulat era combinat cu operația de sincronizare Wait. Timpul virtual putea avansa când mediul era blocat durabil. O blocare care putea fi rezolvată printr-un eveniment exterior nu îndeplinea condiția. Acestea sunt proprietăți ale experimentului documentat, nu afirmația că planificatorul sistemului de operare devenise determinist.

Pentru o echipă de dezvoltare, distincția schimbă sensul unei erori. Un test nereușit al regulilor aplicației ar trebui să indice regula sau modelul folosit de test. Dacă încărcarea mașinii rămâne o explicație plauzibilă pentru fiecare eșec, inginerii mai au o incertitudine de investigat înainte să poată interveni. Eliminarea ei este utilă și fără a pretinde o îmbunătățire măsurată a duratei testelor.

Verificați starea înainte și după tranziție

Luați ca exemplu o regulă care păstrează operația activă până la termenul stabilit. Un test util ar determina starea înainte de expirare, ar muta ceasul controlat la limită, ar permite încheierea operațiilor asociate și ar verifica apoi starea. Verificarea dinaintea limitei contează: un test care urmărește numai anularea eventuală ar putea accepta o implementare care anulează imediat.

Anularea explicită merită un scenariu separat. Aici contează dacă solicitarea de anulare declanșează eliberarea resurselor agreată, indiferent dacă termenul a sosit. Testul propus ar trebui să definească și ce înseamnă această eliberare. Simplul fapt că un context este anulat nu ar fi suficient dacă aplicația promite să elibereze o resursă sau să oprească trimiterea rezultatelor.

Păstrați scenariile suficient de restrânse încât presupunerile despre sincronizare să rămână vizibile. Un test mare, care amestecă reguli de expirare, cereri la distanță și operații fără legătură, poate pierde chiar limita pe care timpul virtual trebuia să o clarifice. Este greu să aveți încredere într-un test care nu poate spune ce operație permite pasul următor, chiar dacă se încheie repede.

Aceasta este o recomandare de proiectare a testelor, nu un experiment efectuat pentru articol. Implementarea exactă ar trebui să urmeze versiunea Go aleasă. Copierea unui exemplu actual într-o discuție despre februarie 2025 ar estompa atât cronologia interfeței, cât și limita de compatibilitate a experimentului. Echipele care întrețin teste vechi au nevoie de această distincție înainte să aleagă exemplele potrivite.

Conexiunea reală oferă în continuare dovezi utile

Cel mai puternic contraargument este că termenul-limită există adesea tocmai fiindcă o dependență reală nu răspunde fiabil. Un apel către baza de date, o conexiune de rețea sau un server extern are un comportament pe care ceasul simulat nu îl reproduce singur. Testul regulii poate stabili reacția codului la un eveniment controlat, fără să arate dacă integrarea reală produce evenimentul în forma așteptată.

Obiecția susține păstrarea unor teste de integrare bine delimitate. Pentru un client de rețea ilustrativ, un test ar putea acoperi regula locală de anulare, iar altul ar verifica efectul întreruperii transportului real. Al doilea își justifică prețul prin verificarea limitei pe care primul o controlează deliberat. Niciun rezultat nu ar trebui prezentat ca dovadă pentru toate ordonările posibile ale execuției sau pentru toate defecțiunile serviciului extern.

Limitele mediului izolat întăresc această împărțire. Nu ar trebui să presupuneți că operațiile I/O externe avansează sub timpul virtual ori furnizează aceleași dovezi de sincronizare ca operațiile interne. O conexiune reală blocată poate rămâne blocată. Ceasul simulat nu înlocuiește nici verificarea consumului de resurse sub o încărcare reprezentativă, dacă aceasta este problema din producție.

Faceți dovezile ușor de citit la mentenanță

O analiză utilă începe cu un test instabil și promisiunea pe care ar trebui să o verifice. Notați tranziția urmărită, observația care dovedește încheierea și partea din mediu care rămâne reală. Alegeți mecanismul abia după aceea. O confirmare explicită printr-un canal poate exprima deja ordinea necesară; timpul virtual este deosebit de util când regula însăși depinde de termene.

Într-un proiect de dezvoltare software la comandă, cereți un test al cărui eșec identifică o promisiune încălcată asupra căreia puteți interveni. Păstrați controlabile regulile de expirare și anulare și mențineți verificările cu I/O real acolo unde contează integrarea. Experimentul synctest din februarie a oferit o modalitate concretă de a gândi această separare. Valoarea lui pentru proiectare vine din distincția dintre „a trecut suficient timp” și „operația relevantă a ajuns într-un punct cunoscut”. Sunt dovezi diferite.