Unitatea care testează o aplicație bazată pe cronometru?

În prezent, scriu o aplicație mini, bazată pe cronometru, în C# care efectuează o acțiune de câte ori la fiecare k secunde Încerc să adopte un stil de dezvoltare bazat pe test, așa că obiectivul meu este de a testa toate componentele aplicației.

Deci, întrebarea mea este: Există o modalitate bună de unitate de testare o clasă pe bază de temporizator?

Problema, așa cum o văd, este că există un mare risc ca testele să dureze în mod incomod de mult pentru a fi executate, deoarece trebuie să aștepte atâta timp pentru ca acțiunile dorite să se întâmple. Mai ales dacă vrem date realiste (secunde), în loc să folosim rezoluția de timp minimă permisă de cadru (1 ms?). Folosesc un obiect machet pentru acțiune, pentru a înregistra numărul de repetări a acțiunii și pentru ca acțiunea să nu aibă practic timp.

0
fr hi bn

4 răspunsuri

0
adăugat

Ceea ce am făcut este să bat joc timer-ul și, de asemenea, timpul de sistem curent, că evenimentele mele ar putea fi declanșate imediat, dar în ceea ce privește codul testat, timpul scurs a fost secunde.

0
adăugat

Sunt de acord cu Danny, în măsura în care probabil are sens din perspectiva testelor de unitate să uităm pur și simplu mecanismul de timer și să verificăm doar că acțiunea însăși funcționează așa cum era de așteptat. Aș spune, de asemenea, că nu sunt de acord că este un efort pierdut de a include configurația temporizatorului într-o suită de testare automată de un fel. Există o mulțime de cazuri de margine atunci când vine vorba de a lucra cu aplicații de sincronizare și este foarte ușor să creați un fals sentiment de securitate prin testarea doar a lucrurilor ușor de testat.

Aș recomanda să aveți o serie de teste care rulează cronometrul, precum și acțiunea reală. Această suită va dura, probabil, un timp pentru a rula și probabil că nu ar fi ceva pe care l-ați rula tot timpul pe mașina dvs. locală. Dar stabilirea acestor tipuri de lucruri într-o construcție automată pe timp de noapte poate ajuta într-adevăr rădăcina bug-urilor înainte de a deveni prea greu pentru a găsi și remedia.

Deci, pe scurt, răspunsul meu la întrebarea dvs. este să nu vă faceți griji cu privire la scrierea a câteva teste care durează mult timp pentru a alerga. Unitatea testează ceea ce puteți și face ca suita de testare să ruleze rapid și adesea, dar asigurați-vă că o completați cu teste de integrare care rulează mai puțin frecvent, dar acoperă mai mult aplicația și configurația acesteia.

0
adăugat

Cred că ceea ce aș face în acest caz este testarea codului care se execută efectiv atunci când timerul bate, mai degrabă decât întreaga secvență. Ce trebuie cu adevărat să decideți este dacă merită să testați comportamentul real al aplicației (de exemplu, dacă ceea ce se întâmplă după fiecare bifare se schimbă drastic de la o bifare la alta) sau dacă este suficient , acțiunea este aceeași de fiecare dată) pentru a testa doar logica.

Deoarece comportamentul timerului este garantat să nu se schimbe niciodată, va funcționa corect (de exemplu, ați configurat-o corect) sau nu; pare să fi fost irosit efortul de a include acest lucru în testul dvs., dacă nu aveți nevoie de fapt.

0
adăugat
Singura problemă pe care o văd cu abordarea dvs. este că va trebui probabil să expuneți ceva care se întâmplă de fiecare dată când se desfășoară sondajele, este o idee bună? și anume expunerea unui lucru pe care nu trebuie să-l faci doar pentru teste. O alternativă ar putea fi internă (și InternalsVisibleTo), dar nici o mulțime de oameni nu le place acest lucru
adăugat autor roundcrisis, sursa