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?
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.
Marked as answer by mvcnoob1 on May 04, 2010 02:54 AM
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.
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.
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).
Marked as answer by mvcnoob1 on May 04, 2010 02:54 AM
mvcnoob1
Member
48 Points
74 Posts
MVC unit testing
Apr 29, 2010 10:23 AM|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?
bradleylandi...
Member
233 Points
109 Posts
Re: MVC unit testing
Apr 29, 2010 02:49 PM|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.
mvcnoob1
Member
48 Points
74 Posts
Re: MVC unit testing
May 03, 2010 01:09 AM|LINK
Doesn't mocking the Update method of the repository mean the unit test knows too much about how the controller action works?
bradleylandi...
Member
233 Points
109 Posts
Re: MVC unit testing
May 03, 2010 08:50 PM|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.
mvcnoob1
Member
48 Points
74 Posts
Re: MVC unit testing
May 04, 2010 12:29 AM|LINK
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.
bradwils
Contributor
5779 Points
691 Posts
Microsoft
Re: MVC unit testing
May 04, 2010 01:21 AM|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).