If you're using Linq to SQL and you want to write unit tests, at some point you're going to have to mock the data context. From what I can tell there's no real great way to do it without abstracting the data context into a factory-like class.
First, you can define your interface:
For your concrete interface:
Then for your mock interface:
From here, you can use any IOC pattern or framework to configure the correct data service.
I really feel like having to wrap the Linq To SQL to support database-free unit testing takes the wind out of the sails of this feature. This makes it so you need to make sure that your repository interface contains all of the possible methods you can imagine using for the business entity.
But the beauty of Linq to SQL is that you don't have to be bound to any of these static methods. Having the power of building the database query through C# is what makes this feature great.
You can always take the "GetAll" method and perform some Linq to Entities, but then you loose the whole query portion of your OR/M layer, which to me, is extremely important.
I wonder if I spent more time on this if there's a better way to mock the data context.