Cum testăm

Ce înseamnă „testat” aici

Un tool care rulează în browserul tău nu are un server pe care să-l supraveghem: dacă ceva se strică, se strică pe dispozitivul tău, în browserul tău, pe fișierul tău. De aceea verificăm înainte de publicare, nu după. Fiecare schimbare din cod, oricât de mică, trece prin aceeași baterie de teste înainte să ajungă pe site.

„Testat” înseamnă aici trei lucruri: tool-ul face ce spune pagina (un PDF comprimat se deschide și arată ca originalul), face asta în browserele pe care le folosesc oamenii, și nu trimite nimic în afară. Nu înseamnă că nu există buguri; înseamnă că cele pe care le-am găsit nu se mai întorc.

Suita automată

Mii de teste rulează la fiecare modificare. Testele unitare verifică bucățile mici: calculul unei ținte de mărime, ordinea paginilor la unire, un interval de pagini scris greșit. Testele cap-coadă deschid site-ul într-un browser adevărat, trag un fișier în pagină, apasă butoanele și verifică rezultatul descărcat, octet cu octet acolo unde se poate.

Testele cap-coadă rulează în trei motoare de browser (cele din spatele Chrome și Edge, Firefox și Safari) și, separat, pe un viewport de mărimea unui telefon, cu atingere în loc de mouse. Dacă un tool merge pe laptop și se blochează pe ecranul unui telefon, testul pică și schimbarea nu se publică.

Documente reale pentru tool-urile PDF

PDF-urile sintetice se comportă frumos; cele din lumea reală nu. Ținem un corpus de documente reale (facturi, formulare, scanări, exporturi din programe de birou și de tipografie) pe care tool-urile PDF rulează la fiecare versiune. Un fișier care a crăpat o dată intră în corpus și rămâne acolo.

Pentru editorul PDF măsurăm fidelitatea după un protocol scris dinainte: fiecare pagină e randată înainte și după editare și comparată pixel cu pixel în afara zonei editate, cu o toleranță fixă, iar fișierul rezultat e verificat cu validatoare independente. Rezultatele sunt numere absolute, față de original, nu o comparație cu alte produse. Publicăm protocolul și rezultatele, inclusiv ce nu a trecut.

Bugete de performanță

O pagină de tool are un buget: cât JavaScript poate încărca, cât de repede trebuie să apară conținutul principal, cât are voie să sară layout-ul. Lighthouse le măsoară la fiecare build, pe un telefon simulat cu rețea lentă; o pagină peste buget blochează publicarea la fel ca un test picat.

Bugetele protejează două lucruri: pe cineva cu un telefon vechi pe date mobile, care trebuie să poată comprima un PDF fără să aștepte, și promisiunea că motoarele grele se încarcă doar când sunt cerute, nu la deschiderea paginii. O verificare separată, garda de rețea, pică un test dacă un singur octet dintr-un fișier de test pleacă din pagină.

Ce nu testăm încă și cum ne spui

Nu testăm pe fiecare telefon și versiune de browser care există, nu testăm cu fișierele tale și nu putem reproduce orice PDF ciudat produs de un program vechi. Când ceva nu merge, spune-ne pe pagina Cere un tool sau în caseta de feedback de sub tool: descrie fișierul (tip, programul care l-a făcut, mărime), fără să-l trimiți. Dacă poți, păstrează-l; un exemplu anonimizat ajunge în corpus și bugul nu se mai întoarce. Cine operează site-ul scrie pe pagina Despre.