visual-studio - 如果我的应用程序只调用 BLL 方法，我为什么要对我的 SQL、DAL 和 BLL 进行 UnitTest？

Question

我已经使用 VisualStudio 集成测试环境进行了一些测试，它们通过调用 BLL 方法来模拟我的 Web 应用程序将执行的操作（它们只是 UI 层应该知道并与之交互的方法）......

因此，如果他们的行为是正确的——我的测试通过了——我为什么要像许多文献建议的那样为 DAL/存储过程等较低层编写测试？

Answer 1

端到端测试很好，可以确保您的应用程序适用于某些场景。

Misko Hevery 在测试分类上发表了一篇很好的博客文章，他将单元测试、集成测试和端到端测试分开。

单元测试 单元测试检查该函数方法中的逻辑是否正确，错误处理是否正确。理想情况下，这些测试应该在几毫秒而不是几秒内运行。如果一个函数需要与 DAL 之类的东西交互，你应该模拟 DAL 的接口，因为真正的交互需要很长时间才能运行。这些提供最佳的投资回报

集成测试 这个级别的测试检查业务逻辑层之间的交互是否完全按照它们应该做的。这是您的单元测试将与接口（如 DAL）交互的地方，并检查“接线”是否正确。应该有一些，但不要太多，因为这会影响您的构建时间

端到端测试 这些很好，因为它们检查从 UI 一直到 DAL 的所有内容。这些测试更多的“接线”并检查您的用户可以做什么不会杀死您的应用程序。这些还可以包括您的FitNesse和 Web 测试，例如Selenium，正在通过。

单元测试提供了最好的投资回报，并且会比其他领域捕获更多代价高昂的错误，但最好能很好地混合这些错误。

Answer 2

从 NUnit 的背景说起

测试 SP/数据访问并不容易。您必须确保每次运行测试时都有一个“干净”的数据库，并在开始时包含预期的数据，以保证您获得预期的结果。因此，您要么每次都需要从干净的备份中恢复数据库，要么确保您的测试在测试开始之前使用所需的数据设置数据库。

理想情况下，单元测试应该尽可能快地运行，这也是为什么在单元测试时经常嘲笑 DAL 的原因之一——以消除昂贵的数据库交互过程。您必须注意的是，如果您确实为 SP/DAL 编写“单元测试”，那么对测试执行时间的影响可能会急剧上升，根据我的经验，这可能会导致人们因为测试时间太长而无法运行测试。特别是在持续集成环境/构建环境中，测试运行时间越长，准备构建的任务就越长。

我个人的看法是，我喜欢在我的单元测试中结合使用模拟和实际的数据库访问，因为我想知道我的代码将在进出数据库的过程中按预期运行，以捕获像 SP 这样的愚蠢错误缺失/错误（介于单元/集成/功能测试之间）。但在不那么重要的地方，我使用模拟。