Cum se automatizează testele de integrare? (Programare, Integrare Continuă, Integrare, Teste De Integrare)

Nicolas Dorier a intrebat.

Aș vrea să știu ceva, știu că pentru a vă ușura testele ar trebui să folosiți mock în timpul testării unitare pentru a testa doar componenta pe care o doriți, fără dependențe externe. Dar, la un moment dat, trebuie să mușcați glonțul și să testați clasele care interacționează cu baza de date, fișierele, rețeaua etc.

Întrebarea mea principală este: ce faceți pentru a testa aceste clase?

  • Nu cred că instalarea unei baze de date pe serverul meu CI este o practică bună, dar aveți alte opțiuni?

  • Ar trebui să creez un alt server cu alte instrumente CI, cu toate dependențele externe?

  • Ar trebui să rulez teste de integrare pe CI-ul meu la fel de des ca și testele unitare?

  • Poate că o persoană cu normă întreagă ar trebui să se ocupe de testarea manuală a acestor componente (sau să se ocupe de crearea mediului de testare și de configurarea interacțiunii dintre clasa dvs. și dependența dvs. externă, cum ar fi editarea fișierelor de configurare ale aplicației).

Aș dori să știu cum vă descurcați în lumea reală.

Comentarii

4 răspunsuri
Jeffrey Fredrick

Aș vrea să știu cum vă descurcați în lumea reală ?

În lumea reală nu există o rețetă simplă cu privire la ce trebuie să faci, dar există un adevăr călăuzitor: vrei să prinzi greșelile/bugs/eșecurile testelor cât mai repede posibil după ce sunt introduse. Lasă acest lucru să fie ghidul tău; orice altceva este tehnică.

Câteva tehnici comune:

  • Teste care rulează în paralel. Aceasta este preferința mea; îmi place să am două sisteme, fiecare rulând propria instanță de CruiseControl* (pentru care sunt committer), unul rulând testele unitare cu feedback rapid (< 5 minute), în timp ce un alt sistem rulează testele de integrare în mod constant. Îmi place acest lucru pentru că minimizează întârzierea dintre momentul în care se întâmplă o verificare și momentul în care un test de sistem ar putea să o prindă. Dezavantajul care nu le place unora este că se poate ajunge la mai multe eșecuri de testare pentru aceeași verificare, atât un eșec al testului unitar, cât și un eșec al testului de integrare. În practică, eu nu consider că acesta este un dezavantaj major.

  • Un model de ciclu de viață în care testele de sistem/integrare se execută numai după ce testele unitare au trecut. Există instrumente precum AnthillPro* care sunt construite în jurul acestui tip de model, iar abordarea este foarte populară. În modelul lor, se iau artefactele care au trecut testele unitare, se distribuie pe un server de pregătire separat și apoi se execută acolo testele de sistem/integrare.

Dacă aveți mai multe întrebări legate de acest subiect, vă recomand Continuous Integration and Testing Conference (CITCON) și/sau lista de discuții CITCON.

Comentarii

  • Minunat, CITCON are o mulțime de resurse! –  > Por Nicolas Dorier.
MattK

Abordarea pe care am văzut-o adoptată cel mai des este de a rula testele unitare imediat la check-in și de a rula teste de integrare mai lungi la intervale fixe (eventual pe un alt server; asta depinde de preferințele dumneavoastră). Am văzut, de asemenea, teste de integrare împărțite în teste de integrare „de scurtă durată” și teste de integrare „de lungă durată”, care se execută la intervale diferite (testele „de scurtă durată” se execută la fiecare oră, de exemplu, iar testele „de lungă durată” se execută peste noapte).

Scopul real al oricărei testări automatizate este de a obține feedback pentru dezvoltatori cât mai repede posibil. Ținând cont de acest lucru, ar trebui să executați teste de integrare cât mai des posibil. Dacă există o variație mare în ceea ce privește durata de execuție a testelor de integrare, ar trebui să executați mai des testele de integrare mai rapide și mai rar testele de integrare mai lente. Frecvența cu care executați orice set de teste va depinde de durata de execuție a tuturor testelor și de cât de mult va perturba execuția testelor pentru testele care se execută mai rar (inclusiv testele unitare).

Îmi dau seama că acest lucru nu răspunde la întreaga dumneavoastră întrebare, dar sper că vă oferă câteva idei despre partea de programare.

David Schmitt

În funcție de natura reală a testelor de integrare, v-aș recomanda să folosiți un motor de bază de date încorporat care este recreat cel puțin o dată înainte de orice execuție. Acest lucru permite ca testele din diferite comenzi să lucreze în paralel și oferă un punct de plecare bine definit pentru teste.

Serviciile de rețea – prin definiție – pot fi, de asemenea, instalate în altă parte.

Aveți întotdeauna grijă, totuși, să păstrați mașina CI separată de orice mediu dev sau prod.

John Croft

Nu știu pe ce fel de platformă vă aflați, dar eu folosesc Java. Acolo unde lucrez, creăm teste de integrare în JUnit și injectăm dependențele corespunzătoare folosind un container DI precum Spring. Acestea sunt rulate împotriva unei surse de date reale, atât de către dezvoltatorii înșiși (în mod normal, un subset mic), cât și de către serverul CI.

În opinia mea, frecvența cu care executați testele de integrare depinde de cât de mult durează execuția acestora. Executați-le cât de des puteți. Lăsați persoana reală deoparte și lăsați-o să execute testele manuale ale sistemului în domeniile pentru care este dificil sau prea costisitor să automatizați testele (de exemplu: ortografia, poziția diferitelor componente GUI). Lăsați editarea fișierelor de configurare în seama unei mașini. Acolo unde lucrez eu, avem variabile de sistem (DEV; TEST și așa mai departe) setate pe calculatoare și lăsăm aplicația să aleagă un fișier de configurare pe baza acestora.