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

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.

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.

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).

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.

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ă).

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.

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.

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ă.

2 cadre de batere recomandate pentru testarea unitatii .net sunt Typemock Isolator si Rhino Mock.

În următorul link puteți vedea o explicație de la Tipul de tip pentru motivul pentru care aveți nevoie de cadru de batjocură . > pentru testarea unităților.