(Acest articol a fost publicat pentru prima dată pe Jakub :: Sobolewskiși a contribuit cu drag la R-Bloggers). (Puteți raporta problema despre conținutul de pe această pagină aici)
Doriți să vă împărtășiți conținutul pe R-Bloggers? Faceți clic aici dacă aveți un blog sau aici dacă nu.
Nu, lipsa de timp nu este unul dintre ei.
Testarea automată este sărbătorită ca piatra de temelie a unui software de înaltă calitate, întreținut. Cu toate acestea, multe echipe încă se luptă să o adopte pe deplin. Obstacolele rareori se reduc la „Suntem prea ocupați” – adevărații blocanți sunt mai profunde și mai fundamentali.
1. Codul dvs. nu este testat prin proiectare
Un blocant major pentru testarea automată: Cod moștenitor care nu poate fi testat prin proiectare.
Multe echipe moștenesc coduri în care arhitectura rezistă activ la automatizarea testelor. S -ar putea să vă confruntați:
- Componente strâns cuplate fără granițe clare, ceea ce face aproape imposibil să testați părțile sistemului în mod izolat.
- Configurația codată greu (cum ar fi referințe directe la bazele de date de producție sau API), ceea ce face ca testarea manuală automată sau chiar sigură, o propunere cu risc ridicat.
- Interfețe lipsă sau puncte de control pentru injectarea dublei, dependențe sau date de testare.
Cu codul care nu este conceput pentru testabilitate, introducerea testelor automate, chiar și testele de acceptare, poate fi o sarcină monumentală. Adesea, este necesară un refactor semnificativ sau chiar o reproiectare arhitecturală înainte de a putea fi adăugată deloc teste automate semnificative. Până când sistemul este făcut „acceptarea testabilă”, fiecare încercare de automatizare lovește un perete.
🧪 Verificați acest ghid privind testarea aplicațiilor strălucitoare.
2. Lipsa datelor de testare
Scrierea testelor automate este ușoară, dacă aveți datele.
Dezvoltarea pe datele de producție ar putea suna mai ușor, dar vine cu riscuri semnificative. Dacă proiectul ar trebui să funcționeze pe date de producție, de ce să vă deranjați să creați versiunea de testare? Este doar o muncă suplimentară, nu?
Este o muncă suplimentară, dar nu veți ajunge departe fără ea.
Fără date de testare accesibile, realiste, testele devin fragile, fie, mai rău, nu sunt scrise niciodată. Nu numai că previne testarea, dar face dificilă noii dezvoltatori și doare reproductibilitatea. Nu ar trebui să oferiți acces la fiecare sistem de producție fiecărui dezvoltator pentru ca aceștia să contribuie la proiect.
Faceți-vă proiectele de sine stătătoare și testabile.
Soluţie
Construiți un catalog de falsuri, machete și fabrici care vă permit să simulați date pentru fiecare bucată izolată a bazei dvs. de cod. Nu numai că testele dvs. vor rula în siguranță, dar vor fi fiabile și ușor de întreținut.
Au structuri de date reutilizabile? Înfășurați fiecare într -o funcție din fabrică pentru a reutiliza testele.
Numesc acele funcții fixture_. În acest fel, când încep să tastez fixture_Primesc autocompletare automată pentru toate meciurile disponibile. Acest lucru face ușor să găsești și să folosești datele corecte în teste.
Dacă un element este utilizat doar într -un singur fișier de testare, definiți -l în fișierul respectiv. Dacă este utilizat în mai multe fișiere, puneți -l într -o locație partajată, de exemplu tests/testthat/setup-fixtures.R.
🧪 Consultați acest ghid cum puteți captura date dintr -o sesiune pentru a salva și reutiliza pentru testare.
Datele dvs. de testare sunt prea mari pentru a fi definite programatic?
Puneți aceste structuri în fișiere, poate fi un JSON, CSV, YAML sau orice alt format care se potrivește nevoilor dvs. Vă recomand să utilizați orice format citibil de oameni, astfel încât să îl puteți citi și edita cu ușurință. Încărcați aceste date în funcția de fixare.
Dacă încărcați aceste date într -o funcție de fixare, le puteți schimba cu ușurință pentru diferite date în viitor și puteți schimba doar funcția de fixare, nu fiecare test care îl folosește.
3. Cuplarea strânsă cu dependențele externe
Codul dvs. funcționează numai atunci când vorbește cu o bază de date „reală” sau cu o API externă? Cuplarea strânsă cu serviciile externe, sistemele moștenite sau medii specializate transformă fiecare test rulată într -un coșmar de intermitență.
Soluţie
Cod refactor pentru a decupla logica de afaceri din dependențe externe prin interfețe, adaptoare sau injecție de dependență.
- Aveți nevoie de o bază de date? Creați o instanță locală și populați -o.
- Aveți nevoie de fișiere dintr -un depozite de date? Înlocuiți -le cu fișiere locale.
- Aveți nevoie de acces la un LLM? Batjocorește răspunsurile.
Cu testthat :: local_mocked_bindings, puteți înlocui dependențele cu date controlate, previzibile, deși injecția de dependență poate obține aceleași rezultate. Pentru a batjocori cu un control mai fin, luați în considerare utilizarea batjocoririi.
Refactor către o arhitectură testabilă.
Începeți prin a permite testele de acceptare automată: introduceți decuplarea, configurația prin fișiere sau variabile de mediu în loc de valori codate greu și interfețe clare, înlocuibile pentru dependențe. Doar după ce aveți o fundație prietenoasă cu teste, puteți introduce în mod sistematic teste automate în codbase.
Izolați -vă de dependențele externe și veți constata că testarea automată devine nu doar fezabilă, ci o parte naturală a procesului dvs. de dezvoltare.
