Pregunta

We are embarking on a new greenfield project in my company and it has been decided that we will use Microsoft's Moles framework for ALL our mocking in unit tests. My manager ideally does not want to introduce any other Mocking frameworks such as NSubstitute or Moq to complicated the project. However I have found that due to the nature in which Moles generates Mocks and Stubs that it does not work nicely with refactoring tools.

For example, we use resharper and if I had the following interface, moles will generate a stub like so:

IMyInterface -> SIMyInterface

Now if I were to refactor IMyInterface to another name such as: IMyNewInterface

then in my unit tests the Stub class is obviously NOT be refactored due to it fundamentally having a different name.

I can see this is a big problem once we get many permutations of unit tests, that refactoring will become a nightmare, and the mantra will be "Just don't change anything!"

Does anyone have similar experiences or know of a refactoring tool that can handle Moles?


Thanks both Merlyn and Mike. My team has decided to compromise and use Moles only for types that we can't mock with standard tools, and then use another framework such as NSubstitute for everything else.

¿Fue útil?

Solución

UPDATE 16 AUG 2012 - Please use Fakes instead of Moles. Fakes are shipped with Visual Studio 2012, and is the fully-supported product release of Moles.

Moles has no 3rd party vendor support; because, it is not an officially released and supported technology, and is still changing. I have created some CodeRush templates that produce Moles and Pex attributes and test methods; however, this doesn't help with refactoring type names.

I agree, your idea to refactor names across the code and test assemblies is a good one. Ironically, the mole types are unable to be refactored, as they come from a compiled assembly. The best you can do is refactor the code, and then perform a search and replace in the test project (yuck.) Yes, this is ugly, especially after refactoring several things.


MOLES SUGGESTION:

I suggest RiSE tweak moles (yet again) to produce a Moles project that is not compiled, rather than generating a compiled assembly. I know the assembly thing is much easier, but I foresee a tremendous This allows the developer to refactor mole and stub type names in the mole classes. Furthermore, refactoring tools, such as Refactor! Pro should be able to automatically refactor both the code and mole type names, across the code, mole, and test projects.

Otros consejos

According to the Microsoft Moles Reference Manual, under “Code Generation Configuration”, on page 11:

It is also possible to disable the compilation, in such case, the Moles code generator will insert the generated C# sources in the project.

It appears the way to disable said compilation is to add a Compilation element as a child of the (root) Moles element if none is present, and add to said child element a ProjectTemplate attribute, setting its value to the path for a .csproj file. This is based on my reading of said attribute’s IntelliSense description displayed by the XML Editor in Visual Studio (taken from the documentation in the Moles schema, which on my computer is at C:\Program Files\Microsoft Visual Studio 10.0\Xml\Schemas\moles.xsd), which reads as follows:

Path to an empty C# project file that will be used to create Moles assemblies project for compilation

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top