If you want to test against IContentRepository you have some different options.
This is basically the same thing as when you’re running the site. In your test project you start up episerver in a console mode and each query/command is executed against the database in the same way it would have been if it had been done via a website.
This is the approach that is the closest to the real deal you’re going to get. It is slower (since it involves a database) and as far as I know there is no EPiServer 7 code available on how to get it to run in non-website way (here’s an example for EPiServer 6 R2).
2. Implementing IContentRepository
As the heading suggest this is method requires the daunting task of implementing the interface and make sure it works in the same manner as the database backed implementation provided by EPiServer. That is, if you in the test save a page as a child of the start page the said page would be returned on a subsequent call to GetChildren for the start page.
Since we don’t really care about the data once the tests are over this implementation is probably using some in-memory storage.
If you implement the interface correctly this is also very close to the real deal. The downside is that you have quite some code to implement for it to mimic DataFactory. But there are short cuts available, like only implementing the subset of feature that is relevant for you site. For example you may not have a site with multiple languages or don’t need versioning of content (in your tests that is).
3. Isolation framework
Using on of these isolation frameworks (Moq, FakeItEasy etc) you can in your test tell your IContentRepository how it should respond to various situations. For instance, when calling GetChildren with a PageReference with 5, then return these 5 pages.
When you want to test how your class interacts with the content repository it may work well. Like if you have tests for your schedule job that fetches data from somewhere and in the end creates a EPiServer page. You can then verify that Save was called with the expected parameters and that may be good enough. However when you actually care about the data, that is a page that is saved should be returned on subsequent loads it can quickly become messy.
Yes, it’s entirely possible to implement the interface and back it with a isolation framework (but it’s not something I’d necessarily recommend).