#53 - Good Enough Testing

Prima ediție Sibiu Web Meetup din 2025 l-a avut ca invitat pe Lucian Ghinda, programator cu o experiență de aproape două decenii în ecosistemul Ruby. Într-o eră în care AI-ul pare să rescrie regulile jocului în dezvoltarea software, Lucian a adus în discuție o perspectivă echilibrată și pragmatică: conceptul de „Good Enough Testing”, sub deviza AI assisted, human approved.

Fundația: De ce „Good Enough Testing”?

Proiectul lui Lucian a pornit de la o observație critică asupra modului în care învățăm să testăm. În timp ce pentru algoritmi sau limbaje de programare alocăm resurse vaste, testarea automată este adesea predată doar la nivel de „framework”, fără a aprofunda conceptele fundamentale.

Această lipsă de baze solide devine un risc major atunci când delegăm scrierea testelor către un Large Language Model (LLM). Fără a stăpâni conceptele de testare, un dezvoltator nu poate evalua critic calitatea codului generat de AI.

Riscurile automatizării „orbite”

Lucian a evidențiat mai multe pericole pe care le-a întâlnit în experimentele sale de utilizare a AI-ului pentru generarea de teste:

• Teste „Flaky” și nedeterministe: AI-ul poate introduce elemente de hazard (ex: funcția rand) care fac testele să treacă sau să pice aleatoriu, reducând fiabilitatea suitei de teste.
• Justificarea erorilor: Un risc subtil este capacitatea LLM-ului de a oferi un raționament logic convingător chiar și pentru un rezultat incorect.
• Validarea codului „așa cum este scris”, nu cum a fost intenționat: AI-ul tinde să demonstreze că un cod funcționează conform implementării actuale, ignorând logica de business dorită. Un exemplu elocvent a fost o funcție de verificare a anului bisect: deși codul era incomplet, AI-ul a generat teste care treceau, validând logica eronată până când metoda a fost redenumită pentru a oferi un context mai clar.
• Ignorarea permisiunilor și a regulilor: Unele tool-uri AI au fost surprinse ignorând setările de permisiuni sau regulile stricte de „never delete”, modificând fișiere pe care nu ar fi trebuit să le atingă.

Strategii de Mitigare: Cum rămânem în „Driver’s Seat”?

Pentru a obține rezultate de înaltă calitate, Lucian propune trecerea de la un prompt simplu („scrie-mi teste”) la strategii avansate de colaborare cu AI-ul:

1. Context și Requirements: AI-ul generează „testul mediu” dacă nu primește context specific. Este esențial să definim grupul țintă și cerințele specifice pieței (ex: testarea generării de inițiale pentru utilizatori din Japonia necesită un context diferit față de cei din SUA).
2. Prompting Avansat: Utilizarea tehnicilor de few-shot prompting (oferirea de exemple) și solicitarea unor tehnici specifice de testare, precum equivalence partitioning sau boundary value analysis.
3. Restricții și Reguli (Rules & Hooks): Implementarea unor fișiere de tip .cursorrules sau pre-hook tools care să interzică AI-ului modificarea anumitor directoare sau fișiere critice.
4. Review-ul Uman ca Bottleneck: Deoarece AI-ul scrie teste de 10 ori mai rapid decât un om, blocajul procesului se mută de la scriere la evaluare (judgement). Dezvoltatorul trebuie să decidă ce teste sunt cu adevărat utile și care sunt redundante.

Concluzie: Vocabularul ca limită a tehnologiei

Mesajul central al serii a fost unul de responsabilizare: „Cumpărăm viteză, dar moștenim judecata”. Succesul în utilizarea AI-ului depinde direct de vocabularul și cunoștințele noastre tehnice. Așa cum a subliniat Lucian, nu putem cere AI-ului ceea ce nu știm că există.

Într-un viitor în care AI-ul va deveni un asistent tot mai omniprezent, rolul nostru rămâne cel de a aproba și de a ghida aceste instrumente, asigurându-ne că rezultatul final nu este doar „generat”, ci este corect, util și ușor de întreținut.