我正在努力让嘲笑工作，改变，并且想知道人们通常把他们的模拟课程放在哪里。我似乎有三个基本选择，但似乎都没有。
我可以将它们放入应用程序程序集本身，在这种情况下它们随应用程序一起提供，这似乎很糟糕，但它们可用于最终构建期间的单元测试，并且没有循环引用。 这似乎是最简单的方法。
我可以创建一个单独的模拟程序集，因此它们在单元测试期间可用，可以从应用程序和测试应用程序中使用，但我最终要么必须将所有实际类型移动到此程序集或创建循环引用。
我可以将它们放在测试程序集中，但是它们无法从应用程序本身使用，因此我无法将它们用作构建应用程序块的过程。
我倾向于尝试使用模拟来帮助开发系统以及测试部件，因此我发现很难知道将它们放在哪里。此外，所有最终版本的代码都必须运行单元测试过程，因此我需要在构建周期中使用模拟。
有没有人想过应该放置模拟类的地方？
感谢您的帮助 Ť
答案 0 :(得分：11)
你的模拟应该进入你的单元测试项目。您的应用程序不应该依赖于您的模拟对象。通常，您的应用程序将使用接口，您的模拟将实现这些接口。您的申请不需要或应该参考您的测试项目。
答案 1 :(得分：2)
模拟应该保存在单独的项目中。我们共有3个选项
单元测试项目中的模拟
如果UI项目需要使用它来启动（例如：模拟服务/部分集成测试/冒烟测试），则无效。即使通过依赖注入在配置文件中引用测试项目，我们也不希望将单元测试dll携带到其他环境。现在更多关注于集成测试Unit tests are less productive，这当然不在本主题之内，但我们应该认识到模拟不仅仅是单元测试。
应用程序中的模拟项目本身（服务模拟） 服务项目）
开发人员可能会意外忘记删除模拟。例如：新开发人员尝试模拟并忘记将其包含在依赖项配置文件中。我们不要把它留给机会，因为它可能阻碍团队的扩张。
在单独的项目中进行模拟。
这里的单元测试项目以及其他启动项目都可以参考。使用前端的集成测试还有可能模拟某个区域（例如：外部API）。或者使用模拟测试UI（而其他团队部署后端）。简而言之，我们有很多选择来使用mock。单独与单元测试无关。 但最重要的好处是，当我们想确保上线时，我们可以从部署中删除模拟项目（或dll）。这样，如果任何项目或配置文件意外地引用了模拟，我们得到运行时错误。这有助于将其扼杀在萌芽状态。
答案 2 :(得分：0)
我们在项目中所做的是识别内部和外部依赖项。内部依赖项的模拟进入单元测试项目（如果在整个解决方案中使用它们，则进入单独的Mocks项目）。外部依赖项的模拟进入应用程序本身，然后用于部署和集成测试。
外部依赖是环境的 - 所以，Active Directory，Web服务，数据库，记录器等等。依赖注入的处理方式相同 - 外部依赖关系在配置文件中定义，因此我们可以在运行时轻松选择要使用的内容。
内部依赖几乎就是其他所有东西。