Skip to main content
1

Crea una guida operativa per la scrittura dei test

Il tuo monorepo di e-commerce ha più di 30 moduli ma solo pochi offrono una copertura dei test significativa. Vuoi passare dal 44% di copertura complessiva all’80% — iniziando dagli 8 peggiori. Prima di avviare sessioni parallele, ti occorre un playbook che garantisca che tutte e 8 le sessioni seguano lo stesso approccio alla scrittura dei test.Chiedi a Devin di creare il playbook per te — ti basta descrivere le tue convenzioni di testing in una qualsiasi sessione:Questo playbook diventa l’insieme di istruzioni condivise per ogni sessione parallela. Puoi anche aggiungere voci in Knowledge sulle tue utility per i test, sui pattern di mocking o su qualsiasi particolarità specifica del progetto (ad esempio, “chiama sempre resetMocks() in afterEach”).
2

Avvia 8 sessioni parallele alle 18:00

Al termine della giornata di lavoro, apri una nuova sessione Devin dalla home page di Devin e descrivi l’attività batch.
  1. Seleziona dal menu a discesa il playbook per la scrittura dei test
  2. Descrivi l’attività nel prompt:
  1. Esamina le sessioni proposte — Devin elenca ogni modulo con la copertura attuale e conferma quali sessioni verranno create:
Proposed sessions (8 modules, all below 50% coverage):
  1. src/services/PaymentService — 31% coverage
  2. src/services/UserService — 38% coverage
  3. src/api/routes/billing — 42% coverage
  4. src/middleware/auth — 44% coverage
  5. src/services/NotificationSvc — 47% coverage
  6. src/components/Checkout — 49% coverage
  7. src/utils/validation — 51% coverage
  8. src/services/SearchService — 53% coverage

Start 8 parallel sessions? (y/n)
  1. Approva il batch e chiudi il laptop. Tutte e otto le sessioni vengono avviate contemporaneamente su macchine Devin separate, ciascuna seguendo il tuo playbook in modo indipendente.
3

Ti svegli con 8 PR

Entro la mattina, ogni sessione si sarà conclusa e avrà aperto la propria PR. Vedrai 8 PR nel tuo repository, ciascuna contenente nuovi file di test e un riepilogo della copertura:
Module                       | Before | After  | PR     | Status
-----------------------------|--------|--------|--------|--------
src/services/PaymentService  |  31%   |  87%   | #412   | Ready
src/services/UserService     |  38%   |  84%   | #413   | Ready
src/api/routes/billing       |  42%   |  91%   | #414   | Ready
src/middleware/auth           |  44%   |  82%   | #415   | Ready
src/services/NotificationSvc |  47%   |  85%   | #416   | Ready
src/components/Checkout      |  49%   |  83%   | #417   | Ready
src/utils/validation         |  51%   |  93%   | #418   | Ready
src/services/SearchService   |  53%   |  86%   | #419   | Ready

Overall coverage: 44% -> 68% (+24 pts across targeted modules)
Unisci le PR nell’ordine che preferisci — poiché ogni sessione aggiunge solo nuovi file di test al proprio modulo, i conflitti sono rari. Se due sessioni hanno modificato un helper di test condiviso, risolvi il conflitto manualmente oppure chiedi a Devin di sistemarlo.
4

Avvia un secondo batch per il livello successivo

Un singolo batch notturno non raggiungerà il tuo obiettivo dell’80% sull’intera codebase. La sera successiva, esegui un secondo passaggio per il livello successivo di moduli:Puoi anche passare dai test unitari ai test di integrazione per i flussi utente critici:Due notti di sessioni parallele possono portare una codebase da meno del 50% di coverage a oltre l’80% — un lavoro che richiederebbe a un ingegnere settimane di impegno dedicato.