We are currently trying to implement Unit Testing on a VB.NET project but we get stucked about the best way to mock data access methods.
We are working on VS2013 Premium so we can use Microsoft Fakes. As far as my understanding goes, Stubs and Shims allow -among other things- to short circuit calls to data access methods and make them return a chosen value (or object or whatever).
During my research I also found about a the Moq mocking framework which doesn't act the same way at all : as far as my understanding goes still, the whole database is mocked.
From these observations, I have few questions :
Optionnally : Do you have good ressources showing best practices to mock data access methods with Microsoft Fakes? All I found until now was pretty light, and not VB.NET focused.
First, you won't find many resources in VB. The best option is to look at the C# resources and then just look at this comparison chart to see what most of it is doing. Ignore a lot of the fancy syntax and just work on instantiating and filling in the parameters with the correct predicates (Function(x)/Sub(x) instead of x => ...).
Close. From the wording of your question, it sounds like you think Moq or Fakes will mock an actual database. It will not make you a fake database (SQL/Raven/etc.). What it does is create you a mocked object of what you need.
So if you have a Repository class, you can set it up to give a proxy back. It may look like your type and work as your type, but it is a "fake" or "mock" of the type. This is why you can force specific values to return. This means if you have a PersonRepository with a method of Find(personId) As Person, you can have it return a new instance (or mock) of Person with the data you need to for the test. You specify what you need. It won't connect to database and the code that would normally be in Find won't run because you didn't really get a true instance of PersonRepository, but of course a mock based on what you told it to set up.
They have close to the same goals, but work completely differently. There are pros and cons for both. One of the main reasons one would lean more towards Microsoft Fakes are Shims. Shims allow the mocking of static and Shared. As far as I know, only Fakes and other 3rd party frameworks that cost money have this feature.
The biggest difference between Fakes and Moq is that Fakes uses code generation to allow stubbing and shimming. You will end up with xAssembly.Fakes.dll in your unit test projects for whatever DLL you need to "fake".
I highly recommend looking at this answer for good information on Fakes.
I don't see why not. They are both going to give you back fake objects that will look like your original object. There's no reason you can't create one object in Fakes and one in Moq. A mocked IRepository is still an IRepository -- doesn't matter which one created it. You can play with both at the same time to see which one you prefer.
Fakes is really good and handy when working with old code that you cannot rewrite, but need to test. Being able to shim statics (Shared for VB) is a great feature. However, I do prefer Moq for normal unit test writing where statics do not come into play (because they shouldn't).