Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
This is probably a really lame question but one I need to ask. Why bother mocking a repository ?
If you’re creating objects with hard coded values and then using Moq to return them as values from method calls on an interface (i.e. without implementation) what exactly are you testing ?
Like the other answers have said, you do this in order to test the client, not the repository (or database, or external service, or whatever), but there’s two key reasons why we do this:
To ensure repeatability and create exceptional cases: You want to be able to know that what you’re testing doesn’t regress over time. If your repository is changing, you can’t be certain that what works now also worked previously. Furthermore, you can identify exceptional cases that may not appear in the repository right now (perhaps a user without a Social Security number, or something similarly obscure but possible) and include them in your test, thereby ensuring future compatibility.
To remove dependencies: You want to make testing as simple and as fast as possible. Every external resource a test relies on is one more barrier to regular testing. If you mock your repository, then tests can be run against your client even if the repository doesn’t exist, or is missing.
For example, if a program hooks into a "real" database, their testing suite might use a local (or even in memory) SQLite database to test their DB behavior, and that way the person running the tests doesn’t need to configure or connect to an actual database, and any changes or errors that occur don’t impact a shared database resource.