Lai pārbaudītu sistēmu, izolējiet blakusparādības

Blakusparādību noņemšana ir viens no labākajiem pārbaudāmā koda veidošanas veidiem

Boksa spēles attēls starp diviem vīriešu cīnītājiem. Viņu sejas ir ārpus rāmja. Kreisās puses cīnītājs ir nosūtījis kreiso āķi cīnītājam labajā pusē. Cīnītājs labajā pusē valkā sarkanu šortu ar nelielu Padomju Savienības simbolu.

Nock ir slavena bibliotēka, kas rakstīta JavaScript, un tā ir noderīga tīkla pieprasījumu novēršanai. Tas atgriež statiskas atbildes uz testiem, lai tās varētu palaist pat tad, ja HTTP serveris nav pieejams.

Tomēr tā ir arī smarža.

Rezultātā iegūtā saikne starp datu avotu un testējamo sistēmu ir izmaksas, kas var ietekmēt koda atjaunošanu un uzturēšanu.

Lūk, kāpēc.

Teiksim, ka ir serveris, kas atgriež ziņu sarakstu, un funkcija, kas patērē šī servera atbildes, lai izveidotu ziņu virsrakstu sarakstu. Funkcijas pārbaudē tiek izmantots Nock, lai aizkavētu servera atbildi:

Diagramma, kas parāda bloku kreisajā pusē ar uzrakstu

Kodam ir pienācīgs pārklājums. Tomēr ar to ir dažas problēmas.

Ja veicat izmaiņas atbildes satura tipā, jums jāmaina testi, pat ja koda uzvedība paliek tāda pati:

Tas pats attiecas uz izmaiņām URL, galvenēm vai parametriem, kurus Nock apgrūtina. Pārbaudes ir jāmaina pat tad, ja sistēmas uzvedība nemainās:

Funkcija "izveidot amatu sarakstu" ir testējamā sistēma (SUT). HTTP zvana dati ir datu avots.

Kodu var noformēt tā, lai datu avotam būtu vispārēja saskarne, kas pievienojama SUT. Tādā gadījumā jūs varat izmantot loģiku, neprasot pārāk daudz iestatīšanas.

Diagramma, kas parāda bloku kreisajā pusē ar uzrakstu “post title list”. Viena bultiņa norāda uz bloku ar uzrakstu “In-Memory Data Source”. Otra bultiņa norāda uz bloku ar uzrakstu “HTTP Server Data”. Avots. ”

Pārbaudes videi var ievadīt “datu atmiņā atmiņā”. Ražošanai var izmantot “HTTP servera datu avotu”.

Iepriekšējā JSFiddle “vispārējā saskarne” ir metode “atrast ziņu virsrakstu”. Neatkarīgi no tā, kā veidojat saskarni, jums ir kontrole pār visiem zvanītājiem. Tāpēc izmaiņas ir vienkāršas. Martins Fūlers to dēvē par “nepublicētu saskarni”.

No otras puses, ja serveris pārkāpj publicētā interfeisa līgumu, piemēram, klases atribūts mainās no pēcnosaukuma uz raksta nosaukumu, jums jāmaina tikai datu avota ieviešana. Jums nav visur jāveic izmaiņas.

Svarīgi ir pārbaudīt un iegūt agrīnu atgriezenisko saiti par testiem, kas saistīti ar izturēšanos, nevis datiem. Tāpēc ir ļoti svarīgi noformēt kodu, lai samazinātu vajadzīgo piepūli loģikas izmaiņām. Šajā gadījumā loģika ir ievades pārveidošana no datu avota uz HTML nesakārtotu sarakstu.

Izmantojot jauno dizainu, jūs esat atdalījis datu avotu no testējamās sistēmas. Tāpēc jūs varat noņemt Nock.

Jaunais dizains arī samazina darbu, kas nepieciešams, lai pievienotu sistēmai jaunu noteikumu bez kopēšanas / ielīmēšanas:

Tomēr “HTTP servera datu avotā” ir kāda nepārbaudīta loģika privātajā funkcijā “vaicājuma ziņu virsraksts no html”.

Lai to pārbaudītu, varat atkārtot to pašu modeli. Piespiediet blakusparādības un padariet mehānismu “saņemt pieprasījumu” ieslēdzamu “HTTP servera datu avotā”. Tādā veidā jūs joprojām varat pārbaudīt kodu, neizmantojot Nock:

Tā kā jums jau ir testi, kas apstiprina, ka “ierakstu saraksts” darbojas ar “atmiņā saglabātu datu avotu”, varat izlemt pārbaudīt datu avotu atsevišķi, lai pārliecinātos, ka tas atgriež pareizo rezultātu:

Jūs esat pilnībā izspiedis blakusparādību no loģikas. Šajā gadījumā blakusparādība ir reālā funkcija “saņemt pieprasījumu”. Tagad to varat izmantot Nock.

Tomēr, tā kā loģika “saņemt pieprasījuma” iekšpusē ir niecīga un Nock rada ievērojamas izmaksas, ir jēga veikt nelielu skaitu integrācijas testu, kas var izmantot visu lietojumprogrammu, ieskaitot blakusparādības. Varat izmantot Nock, lai izvairītos no savienojuma ar tiešu serveri, un joprojām izmantojiet HTTP pieprasījumus, lai pārbaudītu, vai lietojumprogramma sniedz pamatotu atbildi, kad visi gabali ir saderīgi.

Nock ir noderīgs, lai apturētu savienojumu HTTP slānī un nodrošinātu statisku atbildi. Tomēr izmantojiet to taupīgi. Par katru pārbaudi, kuru jūs kavējat, jūs palielināt ievērojamo savienojumu un izmaiņu izmaksas.

Ja Nock netiek izmantots taupīgi, Nock var izveidot Nock elli.

Problēma, kuru vēlaties atrisināt, ir samazināt kļūdu skaitu un izmaiņas. Ja maināt koda struktūru, nemainot uzvedību, testiem nevajadzētu pārtraukties. Ja viņi to dara, tad jums nav izdevies uzrakstīt noderīgus testus.

Jūsu mērķim vajadzētu būt testa pārklājuma kvalitātes uzlabošanai atbilstoši jums rūpīgajai loģikai un savlaicīgai atgriezeniskai saitei. Tas viss, neietekmējot jūsu spēju pārveidot kodu.

Izolējiet blakusparādības un ierobežojiet tādu rīku kā Nock izmantošanu līdz lietojumprogrammas robežām.

Tam vajadzētu dot jums pietiekamu pārliecību, lai veiktu izmaiņas un nesabojātu lietas.

Pievienojieties cīņai, piespiediet blakusparādības un tad… Noņemiet to ārā.

Paldies par lasīšanu Ja jums ir atsauksmes, sazinieties ar mani Twitter, Facebook vai Github.

Paldies Eduardo Slompo un Guilherme J. Tramontina par viņu ieskaujošajām atsauksmēm par šo ziņu.