(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 cădea în capcana scenariilor de scriere până nu rămâi fără idei.
Această abordare ratează economia fundamentală a testării. Ca orice investiție, scenariile BDD respectă legea diminuării randamentelor. Primul scenariu ar trebui să surprindă cea mai mare parte a valorii utilizatorului. Al doilea adaugă un comportament semnificativ. Până la al cincilea, urmăriți cazuri de margine care aparțin testelor de unitate.
Înțelegerea acestei cadențe transformă modul în care abordați BDD. În loc de acoperire exhaustivă a scenariului, vă concentrați pe Livrare de valoare iterativă În cazul în care fiecare scenariu trebuie să -și justifice existența.
Nivelați-vă jocul de testare! Prindeți -vă copia foii de parcurs a testării R.
Începeți cu scenariul de aur
Scrieți scenariul care surprinde mai întâi promisiunea de bază a sistemului.
Pentru software -ul de gestionare a documentelor, aceasta înseamnă fluxul de lucru de aprobare care aduce valoare imediată utilizatorilor. Orice altceva este secundar.
Feature: Document Approval Workflow
As a document reviewer
I want to review and approve documents
So that I can ensure quality before publication
Scenario: Document reviewer approves a document
Given a document "Project Proposal" has been submitted for approval
When I approve the document
Then the document status should be "Approved"
Acest scenariu întruchipează Călătorie primară pentru utilizatori. Se validează că documentele pot fi transmise, revizuite și aprobate. Obțineți această primă specificație de lucru și începeți să livrați imediat valoare.
Observați cum se concentrează scenariul comportament, nu implementare. Nu specificăm tabelele de bază de date, punctele finale API sau elementele UI. Descriem ce experimentează utilizatorii.
Adăugați al doilea comportament cel mai valoros
Al doilea scenariu ar trebui să abordeze următoarea necesitate esențială a utilizatorului.
În aprobarea documentului, respingerea este la fel de critică. Utilizatorii au nevoie de feedback atunci când documentele nu îndeplinesc standardele.
Scenario: Document reviewer rejects a document with feedback
Given a document "Project Proposal" has been submitted for approval
When I reject the document
And I enter the comment "Missing cost breakdown for Q3"
Then the document status should be "Rejected"
And the document should have the comment "Missing cost breakdown for Q3"
Acest scenariu introduce mecanisme de feedback. Se asigură că documentele respinse nu dispar într -o gaură neagră, ci generează o comunicare acționabilă.
Două scenarii acoperă acum Ciclul de aprobare complet. Ați capturat 70-85% din valoarea utilizatorului cu investiții minime.
Reutilizarea pașilor scenariului
Începem să construim un vocabular al modului de a descrie comportamentul sistemului:
Given a document {string} has been submitted for approval
Then the document status should be {string}
Un alt pas parametrizat ar putea fi:
When I {word} the document
Fiecare sistem chiar complex poate fi descris cu un set surprinzător de mic de pași. Dacă nu obțineți suficientă reutilizare, probabil că specificați excesiv scenariile, eventual dezvăluind detalii despre implementare. Acesta este indiciu pentru a le face mai abstracte, dar păstrați -le precis.
Setul nostru de scenarii ar trebui să crească mai repede decât biblioteca de pași pe care trebuie să le implementăm pentru a le rula.
Legea diminuării randamentelor
Dincolo de două sau trei scenarii, fiecare adăugare oferă o valoare mai mică, crescând în același timp întreținerea și costurile de rulare.
După cel de -al treilea scenariu, ești înăuntru Diminuarea teritoriului întoarcerii. Fiecare nou scenariu costă la fel de mult ca și cele valoroase, dar contribuie cu simple puncte procentuale de acoperire suplimentară. Merită să aștepți câteva minute în plus în conducta CI pentru un scenariu care testează un caz de margine rară?
Nu scrieți scenarii pentru cazuri de margine care ar trebui să trăiască în testele unitare.
Apăsați cazurile de margine în jos până la testele unitare
Regulile complexe de validare, condițiile de eroare și cazurile de delimitare aparțin testelor de unități rapide.
Luați în considerare aceste scenarii potențiale BDD care ar trebui să fie de fapt teste unitare:
- Documente cu caractere speciale în nume
- Fluxuri de lucru de aprobare cu 5+ recenzori
- Timeout -uri de rețea în timpul depunerii
- Limitele de dimensiune a fișierului și validarea formatului
- Încercări de aprobare concomitente
Aceste scenarii testează Detalii despre implementare mai degrabă decât un comportament vizibil pentru utilizator. Ei aleargă mai lent, se rup mai des și oferă o perspectivă minimă pentru afaceri.
Testele unitare se ocupă mai bine de aceste cazuri:
test_that("document validation rejects oversized files", {
# Arrange
document <- create_document(size_mb = 50)
# Act
result <- validate_document(document)
# Assert
expect_false(result$is_valid)
expect_equal(result$error, "File size exceeds 25MB limit")
})
Rapid, concentrat și întreținut.
Concentrați -vă pe livrarea de valori iterative
Această abordare se aliniază perfect cu principiile de design iterative.
- Începi cu Comportament viabil minim Aceasta oferă valoare utilizatorului. Expediați -l. Obțineți feedback. Apoi adăugați următorul scenariu cel mai valoros.
- Fiecare iterație oferă software de lucru pe care utilizatorii reali o pot evalua. Evitați să construiți caracteristici cuprinzătoare pe care nimeni nu le dorește.
- Scenariile BDD devin dvs. Busola valorică. Dacă un scenariu nu reprezintă un comportament pe care utilizatorii l -ar lipsi dacă este rupt, probabil că nu ar trebui să existe.
Implementare: castraveți sau DSL intern
Puteți implementa această cadență cu castravete sau cu un limbaj specific de domeniu personalizat (DSL).
Castravetele oferă sintaxa standard Gherkin și maparea definiției pasului:
library(cucumber)
given("a document {string} has been submitted for approval", function(name, context) {
context$driver$submit_document(name)
})
when("I {word} the document", function(action, context) {
context$driver$perform_action_on_document(action)
})
then("the document status should be {string}", function(expected_status, context) {
actual_status <- context$driver$get_document_status()
expect_equal(actual_status, expected_status)
})
În mod alternativ, construiți un limbaj specific domeniului intern care surprinde același comportament:
given_document_submitted <- function(name, driver) {
driver$submit_document(name)
}
when_approving_document <- function(name, driver) {
driver$perform_action_on_document("approve")
}
then_document_status_is <- function(expected_status, driver) {
actual_status <- driver$get_document_status()
expect_equal(actual_status, expected_status)
}
test_that("Document Approval Workflow", {
driver <- new_driver()
given_document_submitted("Project Proposal", driver)
when_approving_document("Project Proposal", driver)
then_document_status_is("Approved", driver)
})
Ambele abordări funcționează. Alegeți pe baza preferințelor echipei și a constrângerilor de scule.
Pentru mai multe detalii despre implementarea driverului și DSL intern, consultați cum am făcut -o în acest tutorial.
Construiți mai întâi lucruri valoroase
Această cadență vă ajută să oferiți valoare mai rapidă și mai previzibil.
În loc să petreceți săptămâni scrise Suite de scenarii cuprinzători, identificați și implementați Comportamente cu cea mai mare valoare mai întâi. Utilizatorii văd progresul imediat.
Evitați capcana acoperirii testelor de jocuri. Fiecare scenariu își câștigă locul reprezentând o valoare autentică a utilizatorului.
Cel mai important, tu Concentrați -vă mai degrabă pe comportament decât pe implementare. Acest lucru vă menține testele rezistente la modificările de cod, asigurându -vă, în același timp, validați ceea ce contează de fapt pentru utilizatori. Dacă sistemul dvs. modifică detaliile implementării, aceste modificări nu vă vor rupe scenariile BDD, atât timp cât comportamentul rămâne consecvent.
Această cadență nu se referă la scrierea mai puține teste.
Este cam Scrierea celor mai valoroase specificații mai întâi și împingând complexitatea către stratul de testare adecvat.
