Rezolvarea unei provocări write-tests

Unele provocări DojoCode îți cer să scrii teste în loc de cod. Implementarea este deja realizată și este corectă. Sarcina ta este să scrii o suită de teste suficient de bună pentru a observa când acea implementare se defectează. 🕵️

Poți recunoaște o provocare write-tests după indiciul albastru de deasupra descrierii:

Write tests for the reference solution. Your tests must pass on the correct implementation and fail on every hidden buggy variant.

Cum funcționează

În culise, autorul provocării a pregătit câteva variante cu bug-uri ascunse ale soluției de referință. Fiecare conține un singur bug mic: o limită greșită, o validare lipsă, o valoare incorectă. Când îți verifici sau îți trimiți testele, DojoCode le verifică în doi pași:

1. În raport cu soluția de referință. Toate testele tale trebuie să treacă. Un test care eșuează pe codul corect este un test greșit.
2. În raport cu fiecare variantă cu bug-uri ascunsă. Pentru fiecare variantă, cel puțin unul dintre testele tale trebuie să eșueze. Când se întâmplă acest lucru, varianta este prinsă.

Finalizezi provocarea atunci când testele tale trec de soluția de referință și prind fiecare variantă cu bug-uri ascunsă.

Bara de acțiuni are câte un buton pentru fiecare etapă a lucrului tău:

Buton	Ce rulează
Test	Testele tale doar pe soluția de referință, cu rezultatul fiecărui test.
Verify tests (Verifică testele)	Ambii pași de mai sus, fără trimitere.
Submit (Trimite)	Ambii pași de mai sus, iar rezultatul contează pentru scorul tău.

Spațiul de lucru

Fig. 1 - Provocarea Add Numbers: Write the Tests: add.js este blocat, testul inițial este deschis, iar descrierea listează regulile pe care testele tale trebuie să le fixeze

• Soluția de referință este vizibilă și marcată cu un lacăt 🔒. Citește-o cu atenție: este comportamentul pe care testele tale trebuie să îl descrie. Nu o poți edita, iar un fișier creat la aceeași cale este ignorat atunci când rulează testele.
• Testul inițial este fișierul în care lucrezi. Acesta conține deja un test care trece pentru a arăta structura și importurile. Adaugă propriile teste lângă acesta sau creează fișiere de test noi.
• Fișierul principal (marcat cu ▶) este punctul de pornire pentru Run (Rulare), atunci când șablonul are unul. Folosește Run pentru a apela soluția de referință și pentru a afișa valori în timp ce o explorezi.

Rularea testelor

Fă clic pe Test pentru a-ți rula testele doar în raport cu soluția de referință. Panoul de rezultate arată aceleași rezultate ca la o provocare clasică: un rezumat al testelor trecute și eșuate, rezultatul fiecărui test, output-ul din consolă și eventualele erori. Variantele cu bug-uri ascunse nu sunt verificate, așa că poți folosi Test ori de câte ori vrei cât timp îți scrii și îți depanezi testele.

Fig. 2 - Test rulează testul inițial și un test nou pentru numere negative doar în raport cu soluția de referință: ambele trec, iar output-ul din console.log apare la Log.

Aici, fiecare test trebuie să treacă. Un test care eșuează pe soluția de referință așteaptă un comportament greșit: corectează așteptarea astfel încât să corespundă cu ceea ce face cu adevărat soluția de referință. Fă clic pe What did I do wrong? pentru a obține o explicație de la asistentul AI.

Verificarea testelor

Fă clic pe Verify tests (Verifică testele) pentru a-ți verifica testele exact cum o face Submit, dar fără să le trimiți: mai întâi în raport cu soluția de referință, apoi în raport cu fiecare variantă cu bug-uri ascunsă. Panoul de rezultate arată unul dintre cele trei rezultate posibile.

Testele tale eșuează pe soluția de referință

Fig. 3 - Testul așteaptă 6 pentru add(2, 3), așa că eșuează pe implementarea corectă (Expected: 6, Received: 5). Panoul listează testele care eșuează, ca într-o provocare clasică, iar variantele cu bug-uri ascunse nu sunt încă verificate.

În această stare, panoul de rezultate arată ca rezultatele unei provocări clasice: un rezumat al testelor trecute și eșuate și arborele testelor eșuate. Diferența este că testele care eșuează sunt ale tale, rulate pe codul corect, deci testul este greșit, nu implementarea. Variantele ascunse sunt verificate doar după ce fiecare test trece.

Corectează mai întâi testele care eșuează: așteptările tale trebuie să corespundă cu ceea ce face cu adevărat soluția de referință. Folosește Test cât timp le corectezi, apoi verifică-le din nou.

Testele tale omit unele bug-uri ascunse

Fig. 4 - Doar testul inițial este scris: acesta trece de soluția de referință și prinde „Off by one”, dar două variante supraviețuiesc

Fiecare variantă ascunsă este listată cu o etichetă și o scurtă descriere a comportamentului pe care îl strică. O bifă verde înseamnă că unul dintre testele tale a prins-o. O cruce roșie înseamnă că toate testele tale încă trec atunci când acel bug este prezent. Citește descrierea, apoi adaugă un test care fixează exact acel comportament.

În exemplul de mai sus, singurul test este expect(add(2, 3)).toBe(5). Acesta prinde „Off by one”, deoarece acea variantă returnează 6. Celelalte două supraviețuiesc: cu două numere pozitive, Math.abs nu schimbă nimic și niciun test nu trimite un șir de caractere. Adăugarea expect(add(-2, -3)).toBe(-5) și expect(() => add('1', 2)).toThrow(TypeError) le prinde pe amândouă.

Fiecare bug ascuns este prins

Atunci când testele tale trec de soluția de referință și fiecare variantă are o bifă verde, panoul raportează All N hidden buggy variants caught. Great tests!, unde N este numărul de variante. Ești gata de trimitere.

Trimiterea rezolvării

Fă clic pe Submit (Trimite) pentru a trimite testele pentru verificarea finală. Trimiterea funcționează exact ca Verify tests, iar rezultatul contează la fel ca la orice altă provocare: se aplică XP, serii (streaks), progresul în concursuri și ecusoanele.

Fiecare variantă ascunsă contează ca un test ascuns suplimentar în scorul tău. O variantă pe care testele tale au omis-o apare ca Hidden bug not caught: <label> și contează ca un test eșuat, așa că o rulare cu succes (verde) doar pe soluția de referință nu va fi niciodată 100%.

Sfaturi pentru a prinde fiecare bug

• Testează limitele. Majoritatea bug-urilor introduse intenționat se află la margini: intrări vide, zero, primul și ultimul element, limita exactă a unui interval.
• Testează erorile. Dacă soluția de referință aruncă o eroare, respinge o cerere sau dezactivează un buton, folosește aserțiuni pentru asta. O validare lipsă este un bug ascuns clasic.
• Folosește aserțiuni pe valori exacte. toEqual('Hello World!') prinde mult mai multe lucruri decât toBeTruthy() sau o verificare de tip.
• Alege intrări relevante. Alege date de intrare în care un bug s-ar manifesta. add(2, 3) nu poate dezvălui un bug cu numere negative, dar add(-2, -3) o poate face.
• Citește etichetele. Eticheta și descrierea unei variante omise îți spun ce comportament să testezi în continuare.
• Mai întâi Test, apoi Verify. Folosește Test pentru feedback rapid pe fiecare test cât timp scrii, și Verify tests după ce testele trec, ca să vezi ce bug-uri ascunse prind.

Pagini înrudite

• 🥋 Rezolvarea unei provocări
• 🧪 Provocări write-tests: cum construiesc autorii aceste provocări
• 📚 Exemple de write-tests după șablon