痣“冲突”将 Moles 与 MsTest 结合使用时
在使用 Moles 和 MsTest 时，我发现了一种可以解释的（但令人沮丧的）行为。
想象一下以下情况：
- “测试 DLL A”在 mscorlib 上使用 Moles
- “测试 DLL B”在 mscorlib 上使用 Moles
为了缩短编译时间，在这两种情况下，我们都在编辑 .moles 文件，以便询问摩尔的生成一个班级。
当我们这样做时，我们的项目将完美编译。
但是，当我们运行解决方案的测试时，MsTest 进程将是：
- 复制“Out”文件夹中的所有 DLL
- 在“Out”文件夹中运行测试
因此，复制到“Out”文件夹将尝试复制两个mscorlib.Moles.dll 的版本（一个类型为 1，一个类型为 2），当然，第二个版本将覆盖第一个版本。
因此，我的“Test DLL A”测试将失败，因为我的鼹鼠程序集不正确。
当然有两个简单的解决方法：
- 要么在每个 .moles 文件中包含所有需要的类型（在所有项目中）
- ，要么不使用类型过滤
您也遇到过这个“问题”吗？还有其他解决方案吗？
非常感谢！
皮埃尔·伊曼纽尔 DotNetHub 用户组负责人
I have found an explicable (but frustrating) behavior when working with Moles and MsTest.
Just imagine the following case:
- "Test DLL A" is using Moles on mscorlib
- "Test DLL B" is using Moles on mscorlib
To improve compilation time, in both cases we are editing the .moles files in order to ask the generation of moles for a single class.
When we do so, our projects will compile perfectly fine.
But when we run the test of our solution the MsTest process will be :
- Copy all DLLs in the "Out" folder
- Run the tests in the "Out" folder
As a consquence, the copy to the "Out" folder will try to copy two version of mscorlib.Moles.dll (one with type 1, and one with type 2) and of course, the second one will overwrite the first one.
And so my test of "Test DLL A" will fail because my mole assembly is not correct.
There are of course two simple workaround :
- either include all needed types (in all projects) in every .moles file
- either do not use type filtering
Have you ever faced this "problem" also ? is there any other solution ?
Many thanks !
Pierre-Emmanuel
DotNetHub user group lead
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我知道这是一个迟到的回复，但我们在我的店里确实遇到了同样的事情。
我们最终做的是创建一个专门针对鼹鼠的项目。然后让所有其他单元测试项目引用在 MolesProject/Moles 文件夹中创建的 .dll。
我们能够利用这一点并缩短构建时间
This is a late reply I know, but we did run into the same thing here at my shop.
What we ended up doing was creating a project just for moles. And then having all other unit test projects reference the .dlls created in our MolesProject/Moles folder.
We were able to leverage that and improve build times