(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.
Aplicația dvs. moștenită Shiny are nevoie de un makeover, dar nu știți de unde să începeți.
Sări direct în refactorizare este ca și cum ai revoca o cameră cu mobilierul încă în interior. Este o rețetă pentru dezastru, creând erori și funcții de rupere pe care nici măcar nu știați că există. Mulți dezvoltatori se încadrează în capcana încercării de a scrie teste de unitate pentru codul monolitic dezordonat, doar pentru a găsi testele lor sunt fragile și se rup cu fiecare mică schimbare.
Există o abordare mai sigură: Scrieți mai întâi teste de acceptare.
Problema cu teste fragile
Când scrieți teste care sunt prea strâns legate de implementarea curentă a aplicației dvs., creați un coșmar de întreținere.
Aceste teste știu prea mult despre lucrările interne, cum ar fi ID -urile componentelor sau structura specifică a UI. În momentul în care un dezvoltator schimbă ID -ul unei componente, testele se sparge. Acest lucru creează frecare și încetinește dezvoltarea, învingând scopul de a face teste în primul rând.
Scopul este să testați comportamentnu implementare.
Procesul în trei etape pentru refactorizare în siguranță
Această abordare axată pe comportament poate fi împărțită în trei pași gestionabili.
1. Document comportament curent
În primul rând, deveniți arheolog. Săpați în trecutul aplicației vorbind cu întreținătorii anteriori și cu utilizatorii de lungă durată.
Nu presupune că știi totul. Scopul tău este să descoperi comportamentul prevăzut. Puneți întrebări de genul:
- Care este obiectivul principal al acestei caracteristici?
- Ce ar trebui să se întâmple atunci când un utilizator efectuează această acțiune?
- Ce date ar trebui să fie afișate acest tabel în aceste condiții?
Folosiți Dat-când-atunci sintaxa pentru a formata aceste comportamente ca specificații. Acest lucru creează o descriere clară, lipsită de ambiguitate a ceea ce face sistemul.
Să ne imaginăm o aplicație simplă strălucitoare. Are o elaborare pentru a selecta o categorie de produse și un buton care generează un complot de tendințe de vânzări pentru această categorie.
Iată cum nu Pentru a scrie o specificație de testare pentru aceasta:
Specificații rele (dezvăluie implementarea)
Feature: Sales Plot Generation
Scenario: User clicks the button to generate a plot
Given the user is on the main page
When they select "Electronics" from the "category_dropdown"
And they click the button with ID "generate_plot_btn"
Then the plot with CSS class ".sales-output-plot" should be visible
Acest test este extrem de fragil. Va eșua dacă:
- Redenumiți dropdown -ul din
category_dropdown. - Schimbați ID -ul butonului din
generate_plot_btn. - Modificați clasa CSS a ieșirii Plot.
Acum, să scriem un test care se concentrează pur și simplu pe obiectivul utilizatorului.
Specificații bune (se concentrează pe comportament)
Feature: View Sales Trends
Scenario: User views the sales trend for a product category
Given the user can view product sales information
When they view the sales trend for "Electronics"
Then they should see the sales trend plot for "Electronics"
Această specificație este curată, lizibilă și descrie valoarea afacerii. Nu -i pasă Cum Utilizatorul selectează categoria sau generează complotul. Implementarea se poate schimba complet, de la un buton la o actualizare automată, iar intenția testului rămâne valabilă.
Fii abstract, dar precis.
2. Creați teste de acceptare executabile
Cu comportamentul documentat, este timpul să -l facem executabil. Aici este un instrument ca un instrument {cucumber} Pachetul pentru R vine.
Castravete vă permite să luați acele specificații Gherkin în limbă simplă și să le conectați la codul care conduce aplicația dvs. Puteți implementa pașii de testare folosind:
{shinytest2},- Dramaturg,
- sau Cypress
Alegerea instrumentului dvs. depinde de expertiza echipei dvs., {cucumber} poate executa pași scrise în R; Dacă utilizați Playwright sau Cypress, scrieți pașii în JavaScript și le executați cu implementarea JavaScript a castravetei.
Pentru a face aceste teste să dureze, trebuie să utilizați selectoare robuste care nu sunt legate de atribute fragile precum clase CSS sau ID -uri generate. Pentru o scufundare mai profundă în acest sens, citiți postarea mea despre crearea selectori de teste robuste care supraviețuiește refactorizarea UI.
3. Refactor și test de unitate cu o plasă de siguranță
Acum aveți o plasă de siguranță.
Suita dvs. de teste de acceptare validează funcționalitatea de bază a aplicației din perspectiva unui utilizator. Cu această plasă în loc, puteți începe refactorizarea cu încredere.
Îndepărtați o logică mare și complexă din partea serverului în funcții mai mici, pure. Pe măsură ce sculptați aceste piese, puteți scrie în cele din urmă teste de unitate vizate pentru ele folosind un cadru precum {testthat}. Testele de acceptare vor semnala imediat orice regresii în comportamentul orientat către utilizator, în timp ce noile teste de unitate asigură corectitudinea componentelor individuale.
Nu sari prea cu nerăbdare la acest pas. Asigurați -vă că mai întâi aveți un set solid de teste de acceptare.
Aplicația dvs. moștenită strălucitoare nu trebuie să rămână moștenire pentru totdeauna. Începând cu comportament, construiți o bază de siguranță care vă împuternicește să vă modernizați baza de cod fără teamă.
Faceți teste aliatul tău, nu dușmanul tău.
