There are several sides to unit-testing:
- Unit-testing is meant to give you confidence that a component works as it should and that future changes don't break any of the current functionality.
- Unit tests should be fast enough that you can execute them often without it feeling as a slowdown in your workflow. How fast they should exactly be and how often you should run them is open for debate (and depends to a large extent on the technology you use and your workflow), but you should still aim for them to be fast enough to not be an unwanted interruption.
- Unit tests should be independent of execution order. If all tests pass, you should be able to execute them in all possible permutations of their execution order and still have all of them pass. In particular, no test must depend on being executed after another test.
With that in mind, lets go back to your question about mocking.
When testing the Repository itself, is mocking going to add anything to the points above? Probably not. The Repository is supposed to be the component that communicates with the Database and you want to verify that that happens correctly. And the tests are probably also not so extensive that it is hard to keep them independent and relatively fast.
When testing the rest of your application, it becomes a different story. As databases are generally very good at persisting stuff, also across test cases, and databases are not the fastest components around, the general experience is that testing against a real database makes it an order of magnitude harder to keep all your tests fast and independent.
As the tests of the Repository give you confidence that that component is working correctly, the advise is to stub/mock/fake it in the other tests. In those tests, your fake Repository can control exactly what gets returned and can do it directly from memory.
To round it all off, you also need a couple of end-to-end integration/acceptance tests to verify that the behavior of the stubs/fakes/mocks is consistent with the behavior of the real components.