Testēšana toBe JavaScript

Kad jūs kaut ko veidojat, jūs vēlaties pārliecināties, ka tas darbojas, un pārliecinieties, ka kaut kas darbojas, to pārbaudot. Tas pats ir ar JavaScript kodu. Pirms tā palaišanas jums ir jāpārliecinās, vai JavaScript kods darbojas.

Šajā rakstā es jums parādīšu, kā tīmekļa izstrādātāji pārbauda savu JavaScript kodu.

Līdz šī raksta beigām jūs varēsiet:

• identificēt dažādus iemeslus, kāpēc izstrādātājs vēlas pārbaudīt savu kodu,
• paskaidrot, kā sarkanā un zaļā faktora cikls ir saistīts ar testēšanu,
• izprast atšķirt manuālo un automātisko testēšanu.

Vienības testēšana.

Kā tīmekļa izstrādātāji pārbauda savu kodu? Noskaidrosim, iekodējot pielāgotu concatStrings funkciju.

Piemēram, es varu izveidot funkciju concatStrings, lai savienotu jebkuras divas virknes, ko es tai piešķiru. Šajā gadījumā es vēlos, lai funkcija savienotu virkni A un virkni B, kas tiek saņemta kā argumenti, un atgrieztu rezultātu.

function concatStrings(virkneA, virkneB) {

return virkneA + virkneB;

}

Piemēram, es varētu uzrakstīt concatStrings a, b, c un pēc tam d, e, f, un atgrieztais rezultāts būtu abcdef.

function concatStrings(virkneA, virkneB) {

return virkneA + virkneB;

}

concatStrings("abc", "def");

Kad funkcija saņem skaitļus 1 un 2, tā atgriež trīs kā skaitli, nevis virkni viens un divi, t.i., 1, 2. Es varu arī norādīt, ko es vēlos, lai funkcija darītu, pievienojot tai komentārus.

function concatStrings(virkneA, virkneB) {

return virkneA + virkneB;

}

concatStrings(1, 2);

Komentāru pievienošana palīdzēs manai komandai saprast un atcerēties paredzēto rīcību, kas man bija saistībā ar šo funkciju.

concatStrings("abc","def"); // "abcdef"
concatStrings("world", "wide"); // "world wide"
concatStrings("123", "456"); // "123456"
concatStrings(1, 2); // "abcdef"

Detalizētāks apraksts būtu labs veids, kā padarīt skaidrāku manu nolūku attiecībā uz katru argumentu. Komentāros es pat varu norādīt sagaidāmo uzvedību, kad funkcijai tiek dotas konkrētas vērtības.

// paredzēts, ka concatStrings atgriezīs vērtību "abcdef", kad kods izpildīsies
// kā pirmais arguments un "def" kā otrais arguments concatstrings ("abc", "def");

Komentāru pievienošana ir solis pareizajā virzienā, taču tai ir arī negatīvās puses. Tas ļauj man rakstīt visu, kas man ienāk prātā, tāpēc neskaidrībām nav ierobežojumu.

JavaScript ir pieejamas daudzas pielāgotas testēšanas sistēmas. Viena no šādu sistēmu stiprajām pusēm ir tā, ka man nav jāizmanto komentāri, lai aprakstītu savu iecerēto iznākumu. Pati testa sintakse kļūst par gaidu dokumentēšanu. Kad es rakstu testus, tie ir labāka alternatīva komentāriem manā pirmkodā, jo tie norāda, kādas cerības mans pirmkods cenšas apmierināt. Testi ir arī izsaucami, kas nozīmē, ka varu veikt testus, lai pārbaudītu, vai cerības ir izpildītas.

Kā jau norādīju iepriekš, es varētu izpildīt funkciju concatStrings, pirmais arguments ir virkne abc, bet otrais arguments ir virkne def. Tad es sagaidu, ka funkcija atgriezīsies abcdef, kad es to izsaucu. Lai to rakstītu kā cerēts dažās testēšanas sistēmās, piemēram, JEST, es varu izmantot funkciju, kuras nosaukums ir gaidīt  “expect”.

expect(concatStrings("abc", "def"))

Pēc tam es nododu izsaukumu funkcijai concatStrings ar konkrētiem argumentiem. Tad es to pievienoju toBe funkcijai, kas ir vēl viena testēšanas funkcija, un nododu tai vērtību, ko es gaidu, lai šis kods radītu.

expect(concatStrings("abc", "def")).toBe("abcdef");

Es būtībā apgalvoju, ka es sagaidu, ka izsaucošās concatStrings ar abc un def atgriezīs vērtību abcdef. Pārbaude JavaScript ļauj man pārbaudīt, vai funkcija darbojas tā, kā es plānoju. Pārbaudot kodu šādā veidā, tiek nodrošinātas trīs lietas.

• Īsums, jo tas ir vienkāršs un precīzs, jo ir tikai divi funkciju izsaukumi, lai izskaidrotu, kāds ir sagaidāmais rezultāts.
• Skaidrība, jo jūs precīzi zināt, kādus argumentus jūs sniedzat,
• un atkārtojamību, jo katru reizi varat to palaist atkal un atkal ar tiem pašiem argumentiem.

Tagad es varētu palaist vairākus funkciju izsaukumus, izmantojot šo sintaksi. Piemēram, es varētu sagaidīt concatStrings 123 un 456 kā argumentus un pēc tam funkciju ar argumentu 123456, un katrā gadījumā cerības būs pareizas un kods darbosies, kā paredzēts.

function concatStrings(virkneA, virkneB) {
    return virkneA + virkneB;
}
concatStrings(1, 2);


expect(concatStrings("123", "456")).toBe("123456");

Pārbaudot terminoloģiju, jūs teiktu, ka jūsu testi ir izturējuši. Bet es esmu tikai pusceļā, jo no mana koda joprojām ir iespējams, ka cerības neizdosies. Piemēram, ja es palaižu gaidīšanas metodi un nododu tai funkcijas concatStrings izsaukšanu ar skaitļiem 1 un 2 kā argumentus, mana cerība, ka rezultāts būs 12, neizdosies.

function concatStrings(virkneA, virkneB) {
    return virkneA + virkneB;
}


expect(concatStrings(1, 2)).toBe(12);

Tas ir tāpēc, ka, izmantojot plus operatoru ar divām skaitļa veida vērtībām, tas veic saskaitīšanas matemātisko darbību, nevis savieno divus skaitļus kopā, veidojot skaitli 12, it kā tas veidotu abcdef. Ja es tam dotu abc un def argumentus.

Kad testi neizdodas, jūs sakāt, ka tie ir sarkani, un, kad tie iztur, sakāt, ka tie ir zaļi. Ja pārbaude neizdodas, tā ir zīme, ka man ir jāraksta kods tā, lai tas izturētu savu pārbaudi. Kad tests ir izturēts, man ir jāuzlabo gan lietotnes kods, gan testa kods, taču nemainot ne vienu, ne otru darbību. To sauc par pārstrukturēšanu.

Refaktorings ir process, kurā es rakstu savu funkcijas kodu, lai tas darbotos efektīvāk vai lai tas būtu vieglāk lasāms un tādējādi vieglāk saprotams citiem komandas programmētājiem. Tas tiek darīts, neietekmējot koda radītos rezultātus. Vienīgajām acīmredzamajām izmaiņām, iespējams, vajadzētu būt pašam testam, kura izpildei nepieciešams mazāk laika, jo esmu optimizējis savu pirmkodu. Jūs vienmēr vēlaties rakstīt savu kodu tā, lai tas atbilstu visām cerībām. Visticamāk, daži no jūsu testiem būs sarkani, bet daži no tiem būs zaļi. Sarkanās pārbaudes ir ceļvedis, kā uzlabot savu kodu, lai apmierinātu nepiepildītās cerības. Turpinot precizēt kodu, reaģējot uz sarkanajiem testiem, tas kļūst par ciklisku darbību. To bieži raksturo kā sarkano-zaļo-refaktora ciklu. Šis cikls ir uz testiem balstītas izstrādes jeb TDD pieejas programmēšanai pamatā.

Ļaujiet man izskaidrot TDD pieeju. Pirmkārt, jūs rakstāt nesekmīgu testu, pēc tam rakstāt savu avota kodu, lai iepriekšējais tests tagad tiktu izturēts. Visbeidzot, jūs optimizējat savu avota kodu, nemainot tā rezultātus. Kodam, kas pārbauda citu kodu, ir daudz priekšrocību. Piemēram, varat to palaist tik reižu, cik vēlaties. Testēšanas kodu var palaist automātiski. Pārbaudes var atkārtot bez ievērojamām laika vai pūļu izmaksām. Rezumējot, testēšana ir veids, kā pārbaudīt jūsu cerības attiecībā uz koda darbību.