De ce ar trebui să aplicați și procese de cod curat pentru a testa codul; Devbridge

De ce ar trebui să aplicați și procese de cod curat pentru a testa codul

Majoritatea dezvoltatorilor depun mult efort în crearea unei structuri de cod bune. Aceasta înseamnă numirea claselor și metodelor în mod consecvent, plasarea lor în pachetele potrivite, gruparea lor corectă și adoptarea unor procese bune.

Reguli similare de cod curat ar trebui să se aplice și codului de test, dar această categorie este adesea trecută cu vederea.

Drept urmare, dezvoltatorii au adesea opinii diferite cu privire la modul de scriere a testelor. Opiniile diferite nu sunt întotdeauna un lucru rău, dar dacă doriți să adăugați o anumită comandă la baza dvs. de testare, acest articol vă poate ajuta.

În acest articol, voi examina câteva dintre liniile directoare pe care le urmăm pentru a menține codul de testare organizat atunci când lucrăm la proiecte Java. Este posibil ca aceste linii directoare să nu funcționeze întotdeauna pentru proiectul sau echipa dvs. specifică, dar totuși merită luate în considerare atunci când începeți următorul proiect.

procese

Testele separate

Clasificare

Înainte de a separa testele, trebuie să identificăm diferitele categorii. În teorie, acest lucru ar trebui să fie ușor: există teste unitare, teste de integrare și teste end-to-end. Tot ce trebuie să faceți este să le separați. Cu toate acestea, există zone gri. Unele teste de integrare pot fi grupate cu teste unitare, iar unele teste unitare pot utiliza dependență externă, dar totuși pot fi etichetate teste unitare.

În Blogul de testare Google, există un articol despre aruncarea denumirii standard pentru teste și introducerea testelor „mici”, „medii” și „mari”. Nu mergem la aceste extreme, dar viteza testului este un bun indicator al modului în care ar trebui clasificat. Poți decide cât de strict vrei să fii. De obicei, separăm testele după cum urmează:

Separare

Testele de unitate și de integrare sunt plasate împreună și separate prin denumire. Clasele de teste unitare se termină cu * Test.java; testele de integrare se încheie cu * IT.java. Acest lucru permite partajarea utilităților de testare între teste de integrare și teste unitare, dar deoarece testele de integrare sunt mai lente, este incomod să le rulați în mod repetat. JUnit 5 va accepta etichete și va deschide noi posibilități în viitor. Deocamdată, dacă utilizați JUnit 4, există alte modalități de a rula testele.

În mod implicit, pluginul Maven Failsafe recunoaște **/IT * .java, **/* IT.java, și **/* ITCase.java (sau poate fi configurat la). Trebuie pur și simplu să activați acest plugin adăugându-l la pom.xml și rulați comanda „mvn verifica”. IntelliJ nu acceptă separarea testului din cutie, dar poate fi configurat cu ușurință prin crearea a două configurații de rulare:

Toate setările sunt implicite - doar modelele sunt diferite. Acestea pot fi reglate pentru a acoperi mai multe cazuri, dar pentru majoritatea cazurilor, aceste modele simple regex ar trebui să funcționeze:

Testele de sistem nu necesită, de obicei, accesarea codului sursă al aplicației. Sunt scrise așa cum sistemul va fi consumat de alte sisteme. De exemplu, dacă este un serviciu REST, atunci aceste teste ar trimite cereri HTTP pentru afirmarea răspunsurilor. Acestea ar trebui plasate într-o sursă separată rădăcină sau - chiar mai bine - într-un proiect separat. Prin urmare, nu este necesară nicio lucrare suplimentară pentru a le rula separat.

Păstrarea codului acoperit

Chiar și atunci când echipa dvs. decide să aibă o acoperire bună a testelor, nu este întotdeauna ușor să respectați acest obiectiv. Pe măsură ce proiectele progresează sau pe măsură ce echipa crește, logica importantă poate ajunge să fie descoperită de teste (trebuie să faceți o soluție rapidă, este sfârșitul sprintului și caracteristicile nu sunt încă finalizate etc.).

Pentru a menține codul bine testat, cel mai important lucru este să înțelegem în comun echipa. Dacă membrii echipei nu doresc să scrie teste sau nu văd avantajul utilizării lor, nicio sumă de sfaturi sau strategii nu vă va ajuta.

Păstrarea testelor curate

Poate părea evident, dar dezvoltatorii încearcă adesea să refactorizeze codul de producție și uită că aceleași reguli de cod curat se aplică și codului de testare. Dacă codul de testare este o mizerie, modificările pentru clasă sau funcție nu vor fi testate - nimeni nu va dori să atingă codul. Pentru astfel de teste, dezvoltatorii schimbă de obicei codul de producție și apoi încearcă să remedieze testele nereușite schimbând afirmațiile pentru a se aștepta la un comportament nou.

Odată, a trebuit să actualizez unele logici ale clientului serviciului web, am găsit o logică ciudată și m-am gândit că, făcându-l să arate „în mod corect”, am îmbunătățit codul. S-a dovedit că serviciul web era buggy. A funcționat doar cu acele valori ciudate, dar pentru că nu a fost clar în test, am crezut că este o greșeală - atât în ​​test cât și în codul de producție.

Rulați întotdeauna teste

Există momente în care poate fi necesar să ignorați temporar unele teste. Este rar, dar se întâmplă. Dacă ignorați testul prea mult timp, logica de afaceri se poate schimba atât de mult încât este mai ușor să ștergeți testul și să îl uitați.