将Nunit测试添加到现有解决方案的公认实践是什么？

Question

我继承了一个没有自动化测试的合理大小的ASP.net解决方案。该解决方案似乎将所有的源代码/页面都包含在一个解决方案中，没有名称间隔，也没有分层，因此在文件等代码中有直接的SQL调用。

在对这个站点进行更改之前，我想添加一些单元测试，最好使用nunit，因为我熟悉Xunit模型，以使我相信我没有破坏任何东西。我没有太多的.net经验，特别是我不确定什么时候使用项目和解决方案等，尽管我对C#的基本语法等很满意。

向解决方案添加单元测试的推荐方法是什么？我应该为测试创建一个单独的解决方案/项目，然后添加对现有解决方案的适当元素的引用，还是应该在现有解决方案中创建一个单独的项目来容纳测试套件。

我真的在寻找这两种方法的优缺点，或者实际上是另一种方法。人们对实现这一目标的最佳方式有什么经验？

Answer 1

我不确定你是否可以从单元测试开始。记住，第一条规则是“不要破坏正常的东西”，我建议从使用WatiN或Selenium之类的东西开始一些集成或回归测试。这两个框架都可以从单元测试框架(如NUnit )运行集成测试。Telerik也做了一个，但它不是免费的，我还没有用过它。

一旦你准备好了，你就可以开始将代码移动到层中的过程了，因为你知道你没有破坏网站。这就是引入单元测试的好时机。

我会通过一个包含所有单元测试的项目来做到这一点，并引用包含您正在测试的类的项目。我相信将你的层次划分到项目中也是一个很好的实践。

Answer 2

我更喜欢同一解决方案中的新项目。

优点：

1. 您的测试始终与测试代码同时编译。
2. 您的测试代码位于单独的程序集中，因此您始终在测试公共代码。

您的测试与测试代码不在同一项目中，您不必将测试与应用程序一起部署。

缺点：

1. 您创建了一个并行名称空间层次结构，如果您移动被测代码，则应该维护该名称空间层次结构。当有很多项目时，像resharper这样的工具会让这个easier.
2. Visual studio变得有点慢。对于数量较少的项目来说不是问题。

Answer 3

我会将测试放在同一解决方案中的不同项目中，这样它们就不会与生产版本一起分发。

看看Michael Feathers所写的有效使用遗留代码，他有很多关于在未经测试的代码中引入单元测试的技巧。

有一些重构可以使单元测试变得更容易，而且不会改变程序逻辑(例如，Visual Studio中内置的重构)，你可以在初始阶段使用它们来改进你的程序结构。

不要害怕在启用单元测试的初始阶段让代码变得“更糟糕”(比如将方法或字段设置为公共的，而这些方法或字段应该是私有的，或者将所有内容都设置为虚拟的)，只要您在测试就绪时使代码变得更好即可。

这包括在生产代码本身中临时添加测试:第一项业务是测试代码，您可以稍后移动测试。