我已经忍了使用VisualStudio的综合测试环境的一些测试， 他们simultate什么我的web应用程序会做通过调用BLL方法 （他们唯一的UI层应该知道和互动）...如果我的应用程序只能调用BLL metods，为什么要为我的SQL，DAL和BLL做UnitTest？
所以如果他们的行为是正确的 - 我会通过我的测试 - 为什么 我会为许多 文献指示我要做的低层编写测试，例如DAL /存储过程？
谢谢大家，彼得。
端到端测试很好，并确保您的应用程序适用于某些场景。
Misko Hevery在test categorization上发表了一篇很好的博客文章，他分裂了单元测试，集成测试和端到端测试。
单元测试 单元测试检查该函数方法中的逻辑是否正确执行了错误处理，并且错误处理是否正确完成。理想情况下，这些测试应该在几毫秒内运行，而不是几秒钟。如果一个函数需要与某些东西交互，比如DAL，那么你应该嘲笑DAL的这个接口，因为真正的交互需要很长时间才能运行。这些提供投资
最好的回报集成测试 这种测试水平检查业务逻辑层之间的交互也正是他们应该做的事情。这是您的单元测试将与接口交互的地方，如DAL，并检查“接线”是否正确。应该有其中的几个，但没有太多，因为这将影响您的构建时间
端至端测试 这些都是很好的，因为他们检查一切从UI挂在一起，一路下跌至DAL。这些测试需要更多的“接线”，并检查你的用户可以做什么不会杀死你的应用程序。这些还可以包括您的FitNesse和网络测试，如Selenium，正在通过。
单元测试提供了最好的投资回报，并且会比其他地区获得更多昂贵的错误，但它有很好的组合。
从NUnit的背景
测试SPS /数据访问说起是不容易的事情。每次测试运行时，您都必须确保您拥有一个“干净”的数据库，并在一开始就有预期的数据，以保证您获得预期的结果。因此，您需要每次都从干净的备份中恢复数据库，或者确保您的测试在测试开始之前用所需的数据设置数据库。
单元测试理想情况下应该尽可能快地运行，并且是DAL经常在单元测试时被嘲笑的原因之一 - 去除昂贵的数据库交互过程。你必须小心的是，如果你为SP/DAL编写“单元测试”，那么对测试执行时间的影响可能会激增，根据我的经验，可能会导致人们无法运行测试，因为它们需要很长时间。特别是在持续集成环境/构建环境中，测试运行时间越长，准备构建任务的时间就越长。
我个人认为我喜欢在我的单元测试中使用模拟和实际数据库访问的组合，因为我想知道我的代码将按照预期一直运行到数据库和从数据库中捕获愚蠢的错误，如SP缺少/错误（单元/集成/功能测试之间的边界）。但是，如果它不那么重要，我会使用模拟。
请参阅下面的AutomatedTester所做的区别，但它听起来不像是在编写单元测试，其中每个“单元”已被隔离，而是集成测试？ – 2009-07-17 09:05:01