将 Nunit 测试添加到现有解决方案的公认做法是什么？
我继承了一个规模合理的 ASP.net 解决方案，但没有自动化测试。该解决方案似乎将所有源/页面包含在一个解决方案中，没有名称空间，也没有分层，因此文件后面的代码中有直接的 SQL 调用等。
在对此站点进行更改之前，我想添加一些单元测试，最好使用 nunit，因为我熟悉 Xunit 模型，让我有信心我没有破坏任何东西。我没有太多的 .net 经验，特别是我不确定何时使用项目与解决方案等，尽管我对 C# 的基本语法等感到满意。
向解决方案添加单元测试的推荐方法是什么？我应该为测试创建一个单独的解决方案/项目，然后添加对现有解决方案的适当元素的引用，还是应该在现有解决方案中创建一个单独的项目来容纳测试套件。
我真的在寻找这两种方法的优缺点，或者实际上是另一种方法。人们对于实现这一目标的最佳方式的经验是什么？
I have inherited a reasonable sized ASP.net solution that has no automated tests. The solution seems to include all of the source/pages in one solution with no name-spacing and no separation of tiers, so there are direct SQL calls within code behind files etc.
Before making changes to this site I would like to add some unit tests, preferably using nunit as I am familiar with the Xunit model, to give me some confidence that I have not broken anything. I do not have much .net experience, and particularly I am not sure about when to use projects vs solutions etc, although I am comfortable with the basic syntax etc of C#.
What is the recommended method of adding units tests to a solution? Should I create a separate Solution/Project for the tests and then add references to appropriate elements of the existing solution, or should I create a separate project within the existing solution to house the test suite.
I am really looking for the pros and cons of both approaches, or indeed another method altogether. What are peoples experiences of the best way to achieve this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我不确定你可以从单元测试开始。请记住第一条规则是“不要破坏有效的东西”，我建议从使用 WatiN 或 Selenium 等工具进行一些集成或回归测试开始。这两个框架都可以从单元测试框架（例如 NUnit）运行集成测试。 Telerik 也做了一个，但它不是免费的，我还没有使用过。
一旦你做到了这一点，你就可以开始将代码移入层的过程，并且知道你不会破坏网站。现在是引入单元测试的好时机。
为此，我将通过一个项目来容纳所有单元测试，并引用包含您正在测试的类的项目。我相信将您的层分成项目也是一个很好的做法。
I'm not sure you can start with Unit tests. Remembering that the first rule is "Don't break what works", I would suggest starting with some integration or regression tests using something like WatiN or Selenium. Both of these frameworks can run the integration tests from unit test frameworks such as NUnit. Telerik do one as well but it's not free and I haven't used it.
Once you have that in place, you can start the process of moving code into layers with the knowledge that you're not breaking the website. This is then a good time to introduce unit tests.
This I would do by having one project that houses all of the unit tests, with references to the projects that contain the classes you are testing. I believe it's also good practice to separate your tiers into projects.
我更喜欢同一解决方案中的新项目。
优点：
缺点：
I prefer a new project in the same solution.
Pros:
Cons:
我会将测试放在同一解决方案的不同项目中，因此它们不会与生产版本一起分发。
了解 Michael Feathers 的有效处理遗留代码，他提供了大量关于在未经测试的代码中引入单元测试的技巧。
有些重构可以使单元测试更容易，并且不会改变程序逻辑（例如 Visual Studio 中内置的重构），您可以在初始阶段使用它们来改进程序结构。
不要害怕在启用单元测试的初始阶段使代码变得“更糟”（例如将应该私有的方法或字段公开或将所有内容都虚拟化），只要在测试进行时使代码变得更好即可地方。
这包括暂时在生产代码本身中添加测试：首要任务是测试代码，您可以稍后移动测试。
I'd place the tests in a different Project in the same Solution, so they won't be distributed along with the production versions.
Look into Working effectively with legacy code by Michael Feathers, he has a ton of tips on introducing unit tests in untested code.
There are refactorings that make unit tests easier and that don't change the program logic (e.g. the ones built-in in Visual Studio), you can use those in the initial stages to improve your program structure.
Don't be afraid to make your code "worse" in the initial stages to enable unit testing (like making methods or fields public that should be private or making everything virtual), as long as you make the code better when your tests are in place.
This includes temporarily adding tests in the production code itself: the first business is testing the code, you can move the tests later.
我还建议阅读 Michael Feathers 的《有效处理遗留代码》。
至于使用遗留代码时的解决方案结构，我通常会复制现有解决方案文件，将其命名为 <>Test.Sln，并将新的 UnitTests 项目添加到新创建的解决方案文件中。
我为集成测试添加了另一个测试项目，因为我喜欢将单元测试与集成测试分开。
I would also recommend reading Working Effectively with Legacy Code by Michael Feathers.
As for the Solution structure while working with a Legacy code, I usually make a copy of the existing solution file, called it <>Test.Sln, and add a new UnitTests Project to the newly created solution file.
I add another test project for the Integration tests, as I like to keep the unit tests separate from the integration tests.