Da biste testirali sustav, izolite nuspojave

Uzimanje nuspojava jedan je od najboljih načina stvaranja testiranog koda

Slika boksačkog meča dvojice muških boraca. Lica su im izvan okvira. Borac s lijeve strane otpustio je lijevu udicu borcu u desnoj. Borac s desne strane nosi crveni kratki s malim simbolom Sovjetskog Saveza.

Nock je poznata knjižnica napisana JavaScriptom korisna za slaganje zahtjeva mreže. Vraća statički odgovor za testove tako da se mogu pokrenuti čak i ako HTTP poslužitelj nije dostupan.

Međutim, to je i miris.

Rezultat povezivanja između izvora podataka i testiranog sustava trošak je koji može utjecati na ponovnu faktorizaciju koda i održavanje.

Evo zašto.

Recimo da postoji poslužitelj koji vraća popis postova i funkcija koja na tom poslužitelju zahtijeva odgovor da stvori popis naslova postova. Test za funkciju koristi Nock za zaustavljanje odgovora s poslužitelja:

Dijagram koji prikazuje blok na lijevoj strani s naslovom

Kôd ima pristojnu pokrivenost. No, s tim postoje i neka pitanja.

Ako promijenite vrstu sadržaja odgovora, morate promijeniti testove, čak i ako ponašanje koda ostane isto:

Isto se primjenjuje ako unesete promjene u URL, zaglavlja ili parametre koji Nock probijaju. Testove morate promijeniti čak i ako ponašanje sustava ostaje isto:

Funkcija "kreiranje popisa postova" je Sustav pod testom (SUT). Podaci s HTTP poziva su Izvor podataka.

Kôd možete dizajnirati tako da izvor podataka ima opće sučelje koje se može priključiti na SUT. U tom slučaju možete koristiti logiku bez prevelikog podešavanja.

Dijagram koji prikazuje blok na lijevoj strani s natpisom

Za testno okruženje možete umetnuti "Izvor podataka u memoriji". Za proizvodnju možete koristiti "Izvor podataka HTTP poslužitelja."

"Opće sučelje" u prethodnom JSFiddle-u je metoda "pronađite naslov postova". Bez obzira na to kako gradite sučelje, imate kontrolu nad svim pozivaocima. Stoga su promjene izravne. Martin Fowler naziva to "sučelje koje nije objavljeno."

S druge strane, ako poslužitelj prekrši ugovor svog Objavljenog sučelja, recimo da se atribut klase promijenio iz post-naslova u naslov članka, morate promijeniti samo implementaciju izvora podataka. Ne morate svugdje mijenjati.

Važno je testirati i imati ranu povratnu informaciju na testovima protiv ponašanja, a ne na podacima. Stoga je ključno osmisliti kod kako bi se smanjila količina napora koja je potrebna za promjene logike. U ovom slučaju, logika je transformacija ulaza iz izvora podataka u popis HTML bez narudžbe.

S novim dizajnom ste razdvojili Izvor podataka iz testiranog sustava. Stoga možete ukloniti Nock.

Novi dizajn također smanjuje rad neophodan za dodavanje novog pravila u sustav bez kopiranja / lijepljenja:

Ipak, "Izvor podataka HTTP poslužitelja" ima neku neprovjerenu logiku unutar privatne funkcije "ispitivanje postova postova iz html-a".

Da biste to testirali, možete ponoviti isti obrazac. Pritisnite nuspojave i učinite mehanizam "zahtijevanje" uključivanje u "Izvor podataka HTTP poslužitelja." Na ovaj način još uvijek možete testirati kod bez potrebe za Nockom:

Obzirom da već imate testove za potvrđivanje da "popis objava postova" funkcionira s "Izvorom podataka u memoriji", možete odlučiti testirati Izvor podataka izolirano kako biste bili sigurni da vraća ispravan rezultat:

Potpuno ste potisnuli nuspojavu iz logike. U ovom slučaju, stvarna "get zahtjev" funkcija je nuspojava. Sada možete koristiti Nock da to pokrijete.

Međutim, s obzirom na to da je logika unutar "zahtjeva za dobivanje" trivijalna i Nock ima značajan trošak, ima smisla imati mali broj integracijskih testova koji mogu koristiti cijelu aplikaciju, uključujući i nuspojave. Nock možete koristiti za izbjegavanje veze s aktivnim poslužiteljem, a ipak koristite HTTP zahtjeve za provjeru vraća li aplikacija razuman odgovor kad se svi dijelovi sjedine.

Nock je koristan za uspostavljanje veze u HTTP sloju i za pružanje statičkog odgovora. Međutim, koristite ga štedljivo. Za svaki test koji ubodete povećavate značajno spajanje i troškove promjena.

Ako se ne koristi štedljivo, Nock može stvoriti Nock Hell.

Problem koji želite riješiti je smanjiti broj pogrešaka i troškove izmjena. Ako promijenite strukturu koda bez promjene u ponašanju, testovi se ne smiju slomiti. Ako uspiju, onda niste uspjeli napisati korisne testove.

Vaš bi cilj trebao biti poboljšati kvalitetu pokrivanja testa logikom do koje vam je važno i ostvariti rane povratne informacije. Sve to, a da se ne utječe na vašu sposobnost vraćanja koda.

Izolirajte nuspojave i ograničite upotrebu alata kao što je Nock na granice aplikacije.

To bi vam trebalo dati dovoljno samopouzdanja da napravite promjene, a ne da prekidate stvari.

Uključite se u borbu, gurnite nuspojave, a zatim ... Odjebite je.

Hvala na čitanju. Ako imate neke povratne informacije, obratite mi se na Twitteru, Facebooku ili Githubu.

Zahvaljujemo Eduardu Slompu i Guilherme J. Tramontini na uvidu u komentare na ovaj post.