c# - What to test/mock? -

given following simple service class, in getcategories() method, should test fact categoryrepository.query() method called, or should setting test keeps list of categories , returns those?

i guess saying mocking categoryrepository , verifying it's query method called once cover test case?

public class categoryservice : validatingservicebase, icategoryservice {     private readonly irepository<category> categoryrepository;     private readonly irepository<subcategory> subcategoryrepository;     private readonly ivalidationservice validationservice;      public categoryservice(         irepository<category> categoryrepository,         irepository<subcategory> subcategoryrepository,         ivalidationservice validationservice)         : base(validationservice)     {         this.categoryrepository = categoryrepository;         this.subcategoryrepository = subcategoryrepository;         this.validationservice = validationservice;     }      public ienumerable<category> getcategories()     {         return categoryrepository.query().tolist();     } } 

sample test

[fact] public void getcategories_should_callrepositoryquery() {     var categoryrepo = new mock<irepository<category>>();     var service = new categoryservice(categoryrepo.object, null, null);      service.getcategories();      categoryrepo.verify(x => x.query(), times.once()); } 

it doesn't matter. in both cases (mock + behavior verification vs stub + assertion) achieve exactly same result , require same level of details inner workings of class. stick whichever 1 think more suited in given scenario.

---

unit test posted example of behavior verification. don't assert values instead check whether method called. useful when method call has no visible results (think logging) or doesn't return value (obviously). of course has drawbacks, when such verification methods do return value, , don't check (as case - we'll it).

the stubbing , asserting approach uses collaborators generate value. doesn't check whether methods called (at least not directly, yet such test performed when setup stub , setup works), instead relies on correct flow of stubbed value.

let's go simple example. test method of class, pizzafactory.getpizza looks this:

public pizza getpizza() {     var dough = doughfactory.getdough();     var cheese = ingredientsfactory.getcheese();     var pizza = oven.bake(dough, cheese);     return pizza; } 

with behavior verification you'd check whether doughfactory.getdough called, ingredientsfactory.getcheese , oven.bake. had such calls indeed been made, you'd assume pizza created. don't check factory returns pizza, assume happens if process' steps completed. can see drawback mentioned earlier - can call correct methods return else, say:

var dough = doughfactory.getdough(); var cheese = ingredientsfactory.getcheese(); var pizza = oven.bake(dough, cheese); return garbagebin.findpizza(); 

not pizza ordered? notice correct calls collaborators happened assumed would.

with stub + assert approach looks similar except instead of verification have stubbing. use values generated earlier collaborators stub later collaborators (if somehow wrong dough or cheese, oven not return pizza wanted). final value method returns , assert:

doughfactorystub.setup(df => dg.getdough).return("thick"); ingredientsfactorystub.setup(if => if.getcheese()).return("double"); var expectedpizza = new pizza { name = "margherita" }; ovenstub.setup(o => o.bake("thick", "double")).return(expectedpizza);  var actualpizza = pizzafactory.getpizza();  assert.that(actualpizza, is.equalto(expectedpizza)); 

if part of process fails (say doughfactory returns normal dough) final value different , test fail.

and once again, in opinion in example doesn't matter approach use. in normal environment both methods verify same thing , require same level of knowledge implementation. safe might want prefer use stub + assert approach in case plants garbage bin¹. if such thing happens, unit tests last problem.

---

¹ note might not intentional (especially when complex methods considered).