I like the idea of using an In-Memory Database such as SQLite when testing instead of creating Mocks for my Repositories. This way I can also test the code of my Repositories without any performance issues.
What are the pros and cons of this strategy?
My strategy is when testing my business code, I mock out my repository. When testing my repository, I mock out my data access layer. I use, as much as possible, auto-generated code for my data access layer (LINQ-to-SQL) so there isn't much to test there. What there is (validation stuff, specialized property handling), can usually be tested directly, without mocks. If absolutely necessary (or easier) I will sometimes fake the data layer with a custom, in-memory store built on Lists -- see my blog at http://farm-fresh-code.blogspot.com where I've written about this.
I would say those two strategies are two different things. As you said yourself, with in-memory db you can test your repositories as well, however, you have to test your repositories first to achieve separation of concerns. When you are designing your system, maybe according to the MVC, you want your Controllers before Models/Repositories, because firstly you have to decide what do you want to do and afterthat decide which entities will collaborativelly achieve that goal. So maybe creating controllers and mocking repositories first is a better way, afterwards you can test your repositories using the in-memory database if it is really easy to setup.
It I'm using an ORM, I generally tend to use a sqlite in memory database for testing my apps since I don't have the overhead of setting up the mocks and expected results. There's a speed boost over using a dummy database but I don't expect it to be faster than using a mock. If I were using an SQL adaptor, I would probably use a mock since otherwise, I'd probably have to rewrite the calls.