我一直在关注单元测试主题，老实说，我从未在实时应用程序中看到它。
我对这个问题有点模糊...... 一个简单的例子是，如果我使用数据填充列表框，我会通过调试知道数据是否正在填充，如果不是，那么可能很容易找出原因。此外，如果它不起作用，我不可能把它投入生产，为什么我需要进行单元测试？我没有看到它的重点。
答案 0 :(得分：6)
如果您在网站的完全不同的区域工作，但由于您的代码的构建方式，您所做的更改会破坏使用数据填充列表框的代码，该怎么办？你需要多长时间才能发现它？更糟糕的是，如果团队中的某个 else 做出了这样的改变，该怎么办？有人根本不知道列表框填充代码是如何工作的？或者甚至是那些不知道的人是代码来填充列表框？
单元测试为您提供了一组测试，确保您不会在已经证明有效的程序区域中回归并引入错误，因为您在每次更改和重构后都会运行单元测试。单元测试可让您轻松编程 。
此外，通过将代码设计为 testable ，您必须创建一个松散耦合的体系结构，该体系结构遵循大量最佳实践列表，例如：依赖注入。
答案 1 :(得分：3)
关键是通过使用单元测试，您确信每个类都按预期工作。
除了知道它在某些条件下有效之外，它的价值是什么？
当您重构代码时，更改设计，重新编写（假设的）不相关的代码段，如果您的测试仍然正确运行，您就知道您没有破坏任何功能。
单元测试的目的是确保您编写的代码符合您的期望，并且对它的任何更改仍然符合它们。
答案 2 :(得分：0)
使用测试有很多优点和缺点。以某种方式看看Art Of Unit Testing，本书大大涵盖了单元测试的主题。此外，您还可以找到应该进行单元测试的原因。
在您的示例中，假设您必须在大约15个网页上检查列表框，组合框和其他数据的填充。如果您需要使用调试来测试它，需要多少浏览器重新加载，鼠标点击，断点命中和运行？许多。但是通过单元测试，其中一个核心规则是单击即可简单地运行测试。如果您正确设计单元测试，只需单击
即可测试成千上万的代码答案 3 :(得分：0)
单元测试将为您提供测试逻辑的机会，而无需访问sql server并激活Cassini或IIS Express。 （当然，您需要首先在主项目上实现依赖注入并在测试应用程序上模拟它们）
想想你已经写了数百种测试方法。并且您将批量运行所有测试方法。根据您的数据结构，这可能需要几分钟甚至更长时间。如果您对项目实施依赖注入并在测试中模拟它们，那么购买将需要相当长的时间。
这是一个可以找到关于依赖注入的好文章的来源：http://haacked.com/archive/2007/12/07/tdd-and-dependency-injection-with-asp.net-mvc.aspx
这是我使用单元测试的原因。如果您的项目非常大，我认为您还应该考虑Test-driven development (TDD)