Last post May 04, 2010 02:21 AM by bradwils
Apr 29, 2010 11:23 AM|mvcnoob1|LINK
I've found unit testing is taking lots more effort than originally thought, I'm finding my mock repositories are almost like small in-memory versions of the real database versions. My question is should I be testing the data after calling a controller action
which updates a value in the repository or is that going too far and testing that the result returned from the action is correct is sufficient?
Apr 29, 2010 03:49 PM|bradleylandis|LINK
I would just mock your repository and Expect a call to the Update method when testing your controller. If you check that Update actually did something then you aren't limiting your testing just to the controller, so if there was an error in repository your
Controller unit tests would fail, which isn't what you want.
May 03, 2010 02:09 AM|mvcnoob1|LINK
Doesn't mocking the Update method of the repository mean the unit test knows too much about how the controller action works?
May 03, 2010 09:50 PM|bradleylandis|LINK
If it is a unit test of the controller, it should know exactly how the controller works. What it shouldn't know is what actually happens in the repository.
May 04, 2010 01:29 AM|mvcnoob1|LINK
If it is a unit test of the controller, it should know exactly how the controller works.
I always thought it should be treated somewhat as a black box... i give the input and expect certain output.. how it works internally won't be the concern of unit test.
May 04, 2010 02:21 AM|bradwils|LINK
Your unit tests are testing the controller, not the repository. Providing a fake repository and understanding your components interactions with other components is the correct way to write the test.
Unit testing a component isn't necessarily just about input and output, but any interaction with the "outside world" (of which input and output are just one form).