Testare & calitate

Ce garantează corectitudinea codului Recash astăzi, spus direct.

Recash nu are, momentan, o suită automată de teste unitare sau end-to-end. În loc să pretindem altceva, preferăm să explicăm ce garanții există și de ce ne bazăm pe ele:

  • tipuri stricte, verificate la compilare, pe tot fluxul de date
  • validare la runtime pentru orice date venite de la client
  • verificare manuală structurată pe fluxurile critice

TypeScript strict

Fiecare model din baza de date generează tipuri exacte, folosite neschimbate din backend până în componentele de interfață. Un câmp lipsă sau un tip greșit devine eroare de compilare, descoperită înainte ca vreun utilizator să ajungă la ea.

Loc pentru imagineEditor de cod cu erori TypeScript evidențiate în timp real

Validare la runtime

TypeScript verifică doar la compilare — iar un client HTTP poate trimite, tehnic, orice. De aceea fiecare payload care ajunge la o rută API trece printr-o schemă Zod înainte să atingă baza de date: numărul de sticle este limitat la un interval rezonabil, descrierea nu poate conține date de contact ascunse, valoarea garanției este verificată să fie pozitivă și plauzibilă. Practic, un set de verificări de contract rulate live, pe fiecare cerere primită.

Verificare manuală

Fluxurile critice — postare completă, autentificare, reconectare WebSocket după o pierdere de rețea — sunt verificate manual la fiecare schimbare relevantă, pe mai multe dispozitive și browsere, nu doar într-un singur mediu de dezvoltare.

Pașii următori

Continuarea firească ar fi teste unitare pentru funcțiile pure din lib/ — calculul de distanță, schemele de validare — și teste de integrare pentru rutele critice. Structura actuală este deja pregătită pentru acest pas: logica aplicației stă izolată de framework-ul HTTP, deci poate fi testată fără mock-uri complicate.