Ce este Object Mocking și când îmi trebuie?

Mulți oameni folosesc obiecte mock atunci când scriu teste unitare. Ce este un Obiect Mock ? De ce aș avea vreodată nevoie de una? Am nevoie de un Mock Object Framework?

0
fr hi bn
adăugat autor Michael Freidgeim, sursa

8 răspunsuri

Object Mocking este o modalitate de a crea un obiect "virtual" sau batjocorit dintr-o interfață, dintr-o clasă abstractă sau dintr-o clasă cu metode virtuale. Aceasta vă permite să împachetați unul dintre acestea în propria dvs. definiție pentru scopuri de testare. Este util pentru a face un obiect care se bazează pe un anumit bloc de cod pe care îl testați.

Unul popular pe care îmi place să îl folosesc este numit Moq , dar sunt multe altele ca RhinoMock și numeroasele despre care nu știu.

0
adăugat

Un obiect martor vă permite să testați exact ceea ce scrieți și detalii abstracte, cum ar fi accesarea unei resurse (disc, serviciu de rețea etc.). Bafta vă permite să vă prefaceți că este o resursă externă sau o clasă sau altceva.

Nu aveți nevoie de un cadru de obiecte machete, ci doar extindeți clasa funcționalității la care nu doriți să vă faceți griji în testul dvs. și asigurați-vă că clasa pe care o testează poate să vă folosească machetul în loc de lucrurile reale prin intermediul unui constructor sau setter sau ceva.

Practica va arăta când miturile sunt de ajutor și când nu sunt.

EDIT: Resursele de batjocură sunt deosebit de importante, astfel încât să nu trebuie să te bazezi pe ele să existe în timpul testului și poți să fugi de detaliile despre modul în care există și ce răspund (cum ar fi simularea unui FileNotFoundException sau a unei servicii web care lipsește , sau diferite valori posibile de întoarcere a unei webservice) ... toate fără timpul de acces lent implicat (batjocura se va dovedi mult mai rapidă decât accesarea unor astfel de resurse în test).

0
adăugat

O altă utilizare este că vă va permite să testați alte părți ale sistemului care nu sunt încă construite. De exemplu, dacă clasa dvs. depinde de o altă clasă care face parte dintr-o caracteristică pe care o lucrează altcineva, puteți cere o interfață în mare parte completă, un program pentru interfață și doar machetați detaliile după cum vă așteptați să lucreze. Apoi, asigurați-vă că ipotezele privind interfața au fost corecte (fie în timp ce vă dezvoltați, fie o dată ce caracteristica este completă).

0
adăugat

Am nevoie de un Mock Object Framework?

Cu siguranta nu. Uneori, scrierea bătăilor la mână poate fi destul de obositoare. Dar pentru lucruri simple, nu este deloc rău. Aplicând principiul Ultimul Moment Responsabil pentru a bate cadre, ar trebui să treci numai de la mâna - șicane scrise într-un cadru când ți-ai dovedit că machetele de mână sunt mai multe probleme decât merită.

Dacă începeți doar cu batjocura, săriți direct într-un cadru vă va dubla cel puțin curba de învățare (puteți dubla o curbă?). Cadrele de confuzie vor face mai mult mai multă sens atunci când ați petrecut câteva proiecte care scriu mizerabil mâna.

0
adăugat

Object Mocking este folosit pentru a păstra dependențele din testul unității. Uneori veți avea un test precum "SelectPerson", care va selecta o persoană din baza de date și va returna un obiect Person.

Pentru a face acest lucru, ar trebui să aveți în mod normal o dependență de baza de date, totuși cu obiectul de batjocură puteți simula interacțiunea cu baza de date cu un cadru mock, astfel încât s-ar putea întoarce un set de date care arată ca unul returnat din baza de date și apoi puteți testa codul dvs. pentru a se asigura că se ocupă de traducerea unui set de date unui obiect persoană, în loc să îl folosească pentru a testa dacă există o conexiune la baza de date.

0
adăugat
Ar fi necesar să bateți un obiect atunci când obiectul însuși poate fi setat și trecut înapoi la testele unității. În acest scenariu, care este preferabil și de ce? În cazul meu, am o funcție de strat de domeniu care utilizează un obiect DTO. Acum se pare contra intitiv să scrieți codul folosind Mockito mai degrabă folosind operația .set în obiectul DTO și folosindu-l în testele unității. Exemplu - mockObject.setMessage ("Hello") v / s Mockito.when (mockDTO.getMessage ()), apoiReturn ("Hello"); 10/10 ori aș vrea să merg la prima abordare.
adăugat autor Ashwin, sursa

Câțiva oameni au răspuns deja la "ce", dar aici sunt câteva lucruri rapide pe care mă pot gândi:

  1. Performance

    Because unit tests should be fast, testing a component that interacts with a network, a database, or other time-intensive resource does not need to pay the penalty if it's done using mock objects. The savings add up quickly.

  2. Collaboration

    If you are writing a nicely encapsulated piece of code that needs to interact with someone else's code (that hasn't been written yet, or is in being developed in parallel - a common scenario), you can exercise your code with mock objects once an interface has been agreed upon. Otherwise your code may not begin to be tested until the other component is finished.

0
adăugat

Vă permite să testați modul în care o parte a proiectului dvs. interacționează cu restul, fără a construi întregul lucru și, eventual, a lipsi o parte vitală.

EDIT: Excelent din wikipedia: vă permite să testați codul în prealabil, ca un designer de mașini care folosește un manechin de încercare pentru a testa comportamentul unei mașini în timpul unui accident.

0
adăugat

Dacă este util un cadru de batjocură, depinde parțial de limba codului pe care îl scrieți. Cu un limbaj static, trebuie să depuneți eforturi suplimentare pentru a păcăli compilatorul în a accepta obiectele mocking ca înlocuitor pentru lucrul real. Într-un limbaj tipic dinamic, cum ar fi Python, ruby sau Javascript, puteți să atașați metodele în mod obișnuit la obiect sau clasă arbitrară și să treci ca parametru - deci un cadru ar adăuga o valoare mult mai mică.

0
adăugat