import { PrismaClient } from '@prisma/client';
import { faker } from '@faker-js/faker';
const prisma = new PrismaClient();
// Garantează că Faker produce aceleași date la fiecare rulare în CI
faker.seed(12345);
async function main() {
const systemEmail = 'admin@community.ro';
// Upsert-ul previne erorile de rulare repetată
await prisma.user.upsert({
where: { email: systemEmail },
update: {},
create: {
email: systemEmail,
name: faker.person.fullName(),
role: 'ADMIN',
},
});
}
main()
.then(async () => {
await prisma.$disconnect();
})
.catch(async (e) => {
console.error(e);
await prisma.$disconnect();
process.exit(1);
});Salutare tuturor. Astăzi vreau să vorbim despre cum facem seed-uri în Prisma care chiar funcționează în CI, fără să ne dăm cu capul de pereți când crapă testele de integrare din senin. Am pățit asta la un proiect mărișor, cu vreo 12.000 de utilizatori activi: rulam testele în GitHub Actions, o dată treceau, de trei ori picau pentru că datele generate aleatoriu de Faker nu se mai potriveau cu aserțiunile noastre.
Problema principală cu seed-ul clasic este că majoritatea dintre noi îl scriem doar ca să avem "niște date" în local, la prima rulare. Dar în CI, ai nevoie de predictibilitate totală și de idempotență.
De ce crapă seed-urile clasice în CI?
Majoritatea tutorialelor îți spun să instalezi @faker-js/faker și să dai un simplu prisma.user.create(). În local funcționează de minune. Apeși un buton, ai zece useri noi cu nume amuzante, viața e frumoasă.
În CI însă, apar două probleme majore. Prima este lipsa de idempotență: dacă rulezi seed-ul de două ori pe aceeași bază de date persistentă de test, pipeline-ul va crăpa din cauza constrângerilor de unicitate (de exemplu, același email generat a doua oară). A doua problemă este non-determinismul: dacă Faker generează alt email la fiecare rulare, cum mai scrii un test de integrare care verifică dacă userul cu un anumit istoric se poate loga?
Regula de aur: Folosește mereu Upsert în loc de Create
Cea mai simplă metodă de a asigura idempotența este să înlocuiești complet apelurile de create cu upsert. Da, e puțin mai mult boilerplate, dar salvează ore întregi de debug nocturn.
La proiectul de care vă spuneam, după ce am trecut toate tabelele de nomenclatoare (roluri, categorii, setări globale) pe upsert, am scăpat complet de erorile de tip "Unique constraint failed". Pur și simplu definim un identificator stabil (un email sau un slug fix) și facem update pe un obiect gol dacă recordul există deja în baza de date.
Cum facem Faker determinist?
Dacă totuși ai nevoie de volum mare de date și vrei să folosești Faker pentru a simula scenarii complexe, trebuie să-i setezi un seed numeric la începutul scriptului tau. Astfel, Faker va genera exact aceleași valori, în aceeași ordine, la fiecare rulare.
Trade-off-ul aici e destul de clar. E excelent pentru teste de integrare unde ai nevoie de volum și realism, dar e destul de nasol dacă se schimbă schema bazei de date des; va trebui să actualizezi manual mapările și structura de upsert-uri, ceea ce poate deveni plictisitor la peste 20 de modele în schemă.
Cum integrăm totul în pipeline-ul de CI
În package.json, Prisma caută cheia prisma.seed. Recomandarea mea caldă este să folosiți tsx în loc de ts-node pentru rulare. Este mult mai rapid. Am economisit cam 30% din timpul de bootstrap al testelor în CI doar din schimbarea asta simplă.
În pipeline, secvența voastră ar trebui să fie:
- Ridici baza de date (de exemplu, un serviciu de Postgres în Docker)
- Rullezi
prisma db push(pentru teste ad-hoc rapide) sauprisma migrate deploy - Rullezi
prisma db seed
Dacă folosești upsert-uri corecte, pasul de seed poate rula oricând, chiar și peste o bază de date parțial populată, fără să strice nimic.
Voi cum gestionați datele de test în CI? Mergeți pe seed-uri masive scrise direct în Prisma sau preferați să faceți restore la un dump SQL curat înainte de fiecare rulare de teste?