Aproape 3.000 de teste mențin înghețat nucleul nostru de calcul

Un nucleu de calcul înghețat înseamnă că numărul arătat ieri unui client rămâne același și azi. Circa 750 de teste backend și 2.100 de teste frontend garantează asta.

26 august 2026 · 5 min

Cum aproape 3.000 de teste mențin înghețat nucleul de calcul din TV Budgeting

Păstrăm această suită de teste pentru o singură proprietate care se vinde prost într-o broșură, dar se dovedește esențială zi de zi: aceleași date de intrare trebuie să producă aceleași rezultate în orice versiune a instrumentului. Aici „aproximativ corect” nu e o categorie.

De ce calculele media nu au un mod „cam așa”

Un calcul media trăiește mult timp și trece prin mai multe mâini: licitație, apoi contract, apoi post-buy. La fiecare predare, numărul devine o obligație față de altcineva — clientul, casa de vânzări, finanțele. Un dashboard de analytics are un alt profil de risc: o cifră greșită e observată și corectată la următoarea revizuire.

Când un coeficient se schimbă discret între două versiuni, paguba nu rămâne într-o singură celulă. Suma contractată nu mai corespunde cu argumentația pe baza căreia a fost aprobată, iar discuția începe cu cea mai proastă întrebare posibilă: care versiune calcula corect? Dacă logica nu a fost fixată de la început, nimeni din sală nu poate răspunde.

Două straturi în care calculul cedează cel mai des

Discounturile casei de vânzări sunt cazul cel mai clar. Ele se înmulțesc, nu se adună:

combined = 1 − ∏(1 − r)

Așadar 20% și 10% dau 28%, nu 30%. Două puncte procentuale par neglijabile până le înmulțești cu bugetul unei campanii. Formula „vrea” să alunece spre adunare, și acolo alunecă de obicei — într-o copie a fișierului editată de altcineva, sau în graba de dinainte de trimitere. Un test fixează regula: adunarea procentelor blochează build-ul, în loc să iasă la iveală la masa negocierilor.

Al doilea strat e mai subtil și greu de verificat manual. Ciclul buget → prag de discount → buget converge prin iterație: bugetul stabilește pragul, pragul mută bugetul, se repetă până când perechea se stabilizează. Uneori valoarea oscilează între două praguri vecine și nu se fixează pe niciunul. Atunci nucleul alege bugetul mai mare — alegerea prudentă pentru un cumpărător, căci a rezerva o marjă e mai sigur decât a descoperi un deficit în timpul execuției. Nimic din toate acestea nu se vede în interfață, iar cazurile obișnuite nu ajung niciodată aici. Un refactor aparent inofensiv o poate strica, iar cineva observă abia peste un trimestru, fără nimic cu care să mai compare.

Cum arată eșecul celor două straturi
Cumularea discounturilor — simplificată discret la adunare; eroarea crește odată cu bugetul; prinsă de un test unitar pe formula ratei combinate.
Iterația pragurilor — regula de oscilație eliminată într-un refactor; invizibilă în interfață; prinsă doar de un test care verifică regula bugetului mai mare la egalitate.

Înseamnă „înghețat” că produsul nu mai evoluează?

Nu. Înghețat înseamnă că orice schimbare a unui rezultat e deliberată, explicabilă și vizibilă chiar în ziua respectivă, nu descoperită surprinzător câteva luni mai târziu. Lansăm continuu. Ce blocăm este o diferență numerică strecurată ca efect secundar al unei modificări fără legătură; fiecare astfel de schimbare trece printr-o decizie explicită.

Reperul nostru este nucleul însuși: aceleași date de intrare dau același rezultat la fiecare build. La implementare reconciliem suplimentar, celulă cu celulă, cu modelul cu care vine agenția, astfel încât migrarea să nu rupă istoricul deja aprobat de client — această poartă se menține sub 0,01% la fiecare build, nu este aprobată o singură dată la început. Dacă abaterea crește, build-ul nu trece. Cifrele Nielsen le reproducem exact la valorile primite; stratul de calcul nu are ce căuta să reformeze datele de intrare după bunul plac.

Testele ca protocol, nu ca QA

În practică, aceste teste funcționează ca un protocol. Ele păstrează sub formă executabilă înțelegerile despre matematica din spate — scoase din capul celui care a scris formula, scoase dintr-un comentariu de celulă care rezistă cel mult o predare de fișier. Reproductibilitatea separă un instrument de un spreadsheet mult mai hotărâtor decât o face interfața; detaliem această comparație în Alternative la platformele enterprise de media planning

.

O limită clară: CPP-ul din TV Budgeting este un proxy de planificare, nu un preț contractat. Un nucleu înghețat garantează că aritmetica e stabilă și repetabilă. Nu transformă un proxy în dovadă a costului real, a economiilor sau a ROI-ului.

Nimic din toate astea nu e spectaculos. Încrederea într-un instrument de media planning se construiește pe predictibilitate, nu pe numărul de funcții: aceleași date de intrare trebuie să dea același rezultat, în orice versiune. Tot restul se sprijină pe această proprietate, iar fără ea nimic de deasupra nu rezistă.

FAQ

Ce înseamnă mai exact un „nucleu de calcul înghețat”?

Că orice schimbare a unui rezultat calculat trebuie să fie deliberată, explicabilă și vizibilă chiar în acea zi. Dezvoltarea continuă; deriva numerică silențioasă, nu.

Câte teste acoperă nucleul?

Circa 750 de verificări backend și circa 2.100 frontend — aproape 3.000 în total, rulate la fiecare build.

Ce se întâmplă la migrarea de pe modelul folosit deja de agenție?

Sub 0,01%, verificată la fiecare build, nu doar o dată la implementare. Dacă abaterea crește, build-ul eșuează.

De ce prind testele bucla pragurilor de discount, iar revizia manuală nu?

Regula de oscilație — se alege bugetul mai mare când valoarea oscilează între două praguri vecine — e invizibilă în interfață și absentă din cazurile tipice. Doar o verificare automată o menține în vigoare.

Vedeți nucleul în acțiune

Fiecare regulă descrisă aici rulează în TV Budgeting — discounturi înmulțite, praguri iterate și același răspuns la fiecare rulare.

Solicitați un demo →