Home
-
moq, like the mocking Framework
-
A small animal which should make us think of Unit Testing as something which should be easy and go like a breeze.
-
Ending in RT, as in WinRT
as of now, it is still work in progress and the Framework is not usable at all. Sorry folks ! The main idea behind Moqingbirt, is to keep moq's syntax so that if one day, WinRT gets officially supported, and its implementation is better than moqingbirt, then it will be very easy to switch back to moq, by keeping the same code.
I went through various iterations regarding how to analyze the existing interfaces for which to create mocks, trials and deceptions. Here were the options :
-
Use Roslyn : unfortunately, roslyn does not support WinRT.
-
Use t4 templates : Using reflection on previously built dlls. Unfortunately, reflection would not work on WinMD files, and calling RoGetMetaDataFile from a Template doesn't look like a valid option, as described in the possible HRresults returned : _HR_RESULT_FROM_WIN32(ERROR_NO_PACKAGE) _ The function was called from a process that is not in a Windows Store app. Actually, this was ma preferred approach, as it is free and ships out of the box with visual studio. I've used it extensively in order to build test mocks implementations, until I tried to use it on an actual project which was not managed : ka-boom, assemblies can't be loaded the way they could be in .Net anymore. Frustration.
-
Use t4 templates based on .cs files in raw text instead of analyzing previously built dlls : I have considered it. I did... it just doesn't seem so bullet-proof, and I'd rather go with a more solid language object-model.
-
Use PostSharp : as of october 2012, it is not supported
-
Use the Resharper SDK and write a demon : Resharper is not free, but it certainly should be present on with any proper dev environment. Besides, price for its value is ridiculously low, and will definitely not be only used to use this Framework. As a matter of fact, doing TDD without Resharper is so tedious, that if you are not already using it, you propably aren't even doing TDD at all and you probably will not need this Framework in the first place ;).
-
Use t4 templates, based on the EnvDTE.DTE API. it's based on COM, it's not convenient, t4 templates are not easy to edit without IntelliSense and debugger support, but it's free, ubiquitous, and with DTE, the code of the other projects don't even need to be compiled. It looks like it's the right solution for our needs ! I am going to go down that road and see what gives.
-
Use the IMedatata interface. It requires extensive use of P/Invoke, C# interfaces are not listed on pinvoke.net, but it can do the trick for already-compiled 3rd party dll's for which we don't have the source code, and we can't use the DteEnv API. We will most certainly adopt this approach in the future, but as a first step, we'll stick to mocking the sources we have in our project.