在哪里编写单元测试代码?

单独的项目,相同的解决方案。使用 InternalsVisibleTo 如果您想从测试代码访问内部。

将测试与生产代码分离:

• 更明显的是什么
• 意味着您不需要依赖于生产项目中的测试框架。
• 使部署的代码更精简
• 避免在部署程序集中包含测试数据文件

将代码保持在同一解决方案中:

• 保持测试周期快速
• 使生产代码和测试代码之间的切换变得容易

我总是在编写测试设备的地方创建一个单独的项目。 我不想把我的领域模型(或其他)和测试类放在一起。
我不想将我的测试分发给我的应用程序的客户或用户,因此我将它们放在一个单独的项目中(这也导致了一个单独的程序集)。

如果您有少数情况需要测试内部方法,则可以使用InternalsVisibleTo。 如果您有非常罕见的案例想要测试私有方法,那么可以使用 this 技术,如戴维·布赖恩所解释的。

我更喜欢第一种方法——分离到单元测试,而不是它自己的项目。 将单元测试放在测试对象中会使其变脏。此外,您不一定希望将项目与单元测试一起分发,这将使您的DLL更大,并且可能会公开您不希望公开给最终用户的内容。

我看到的大多数开源项目都有不同的单元测试项目。

您应该将单元测试放在单独的项目中。

您还应该以某种方式编写它们,这样SUT(测试中的系统)就不会以某种方式进行修改,从而使单元测试成为可能。我的意思是,在您的主项目中不应该有“只”支持您测试的助手类。

混合测试和生产代码是一个糟糕的计划,因为你不想把所有额外的代码交付给你的客户。保持另一个项目所提供的清晰分离。

我不认为“保持测试速度快”的论点真的很有力。划清界限…测试代码不属于生产环境。

编辑:

以上编辑评论:

编辑:关于用“测试中的代码”编写单元测试代码:我想从生产程序集中删除测试代码并不难。这就是条件编译的目的。对吗?

是的,删除带有条件编译标志的代码是“容易的”,但是您不会测试您创建的最终程序集,您只测试了使用其中的代码创建的程序集,然后重新编译、创建一个新的未测试的程序集并发送该程序集。您确定所有条件标志都设置为100%正确吗?我想不是,因为你不能运行测试;)