如果我的应用程序仅调用 BLL 方法，为什么要对 SQL、DAL 和 BLL 进行 UnitTest？
我使用 VisualStudio 集成测试环境进行了一些测试， 他们通过调用 BLL 方法来模拟我的 Web 应用程序将执行的操作 （他们只是 UI 层应该知道并与之交互的人）...
所以如果他们的行为是正确的 - 我的测试通过了 - 为什么应该 我为较低层编写测试，例如 DAL/存储过程 文献建议我做什么？
I've put up some tests using VisualStudio integrated test environment,
they simultate what my web application would do by calling BLL methods
(they only ones the UI layer should know and interact with)...
So if their behaviour is correct - I get my tests passed - why should
I write tests for lower layers such as DAL/Stored Procedures as many
literature suggest me to do?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
端到端测试很好，可以确保您的应用程序适用于某些场景。
Misko Hevery 在测试分类上发表了一篇很好的博文他将单元测试、集成测试和端到端测试分开。
单元测试
单元测试检查该函数方法中的逻辑是否执行正确的操作以及错误处理是否正确完成。 理想情况下，这些测试应在毫秒而不是秒内运行。 如果一个函数需要与某些东西（例如 DAL）交互，您应该模拟 DAL 的接口，因为真正的交互需要很长时间才能运行。 这些提供了最佳的投资回报
集成测试
此级别的测试检查业务逻辑层之间的交互是否准确地执行了它们应该执行的操作。 这是您的单元测试与接口（如 DAL）交互的地方，并检查“接线”是否正确。 应该有一些，但不能太多，因为这会影响您的构建时间
端到端测试
这些很好，因为它们检查从 UI 一直到 DAL 的所有内容是否都挂在一起。 这些测试更多的“接线”，并检查您的用户可以执行的操作不会终止您的应用程序。 这些还可以包括您的 FitNesse 和网络测试，例如 硒，正在通过。
单元测试提供了最好的投资回报，并且会发现比其他领域更昂贵的错误，但最好将这些测试进行良好的组合。
End-to-End testing is good and makes sure that your application is working for certain scenarios.
Misko Hevery put a good blog post on the test categorization where he splits unit-test,integration test and end-to-end testing.
Unit-Testing
Unit testing checks that the logic in that function method is doing the correct thing and that error handling is done correctly. These tests should ideally run in milliseconds not seconds. If a function needs to interact with something, like the DAL, you should mock that interface of the DAL since true interaction would take a long time to run. These offer the best Return on Investment
Integration Testing
This level of testing checks that interaction between Business Logic layers do exactly what they should be doing. This is where your unit-test would interact with an interface,like the DAL, and check that the 'wiring' is correct. There should be a few of these but not too many as that would impact your build time
End-to-End Testing
These are good as they check that everything hangs together from the UI all the way down to the DAL. These test a lot more of the 'wiring' and check that what your user can do won't kill your application. These can also include your FitNesse and Web Tests, like Selenium, are passing.
Unit Testing offers the best return on investment and will catch a lot more costly bugs than the other areas but its good to have a good mix of the lot.
从 NUnit 背景来看
，测试 SP/数据访问并不那么容易。 您必须确保每次运行测试时都有一个“干净”的数据库，并在开始时包含预期的数据，以保证获得预期的结果。 因此，您要么需要每次从干净的备份中恢复数据库，要么确保您的测试在测试开始之前使用所需的数据设置数据库。
理想情况下，单元测试应该尽可能快地运行，这也是单元测试时 DAL 经常被嘲笑的原因之一 - 消除昂贵的数据库交互过程。 您必须小心的事情是，如果您确实为 SP/DAL 编写“单元测试”，那么对测试执行时间的影响可能会急剧上升，根据我的经验，这可能会导致人们不运行测试，因为它们花费的时间太长。 特别是在持续集成环境/构建环境中，运行测试所需的时间越长，准备构建的任务就越长。
我个人的观点是，我喜欢在单元测试中结合使用模拟和实际数据库访问，因为我想知道我的代码将按预期一直运行到数据库和从数据库运行，以捕获诸如 SP 之类的愚蠢错误缺失/错误（单元/集成/功能测试之间的边界）。 但如果不是那么重要，我会使用模拟。
Speaking from an NUnit background
Testing the SPs/data access is not as easy to do. You have to ensure you have a "clean" database each time your tests run, with expected data in there at the start to guarantee you get the intended results out. So you either need to restore a db from a clean backup each time, or ensure your tests setup the database with the data it needs before the tests start.
Unit Tests should ideally run as fast as possible, and is one of the reasons why the DAL is often mocked when unit testing - to remove the costly process of database interaction. The thing you have to be careful of, is if you do write "unit tests" for SPs/DAL then the impact on test execution time could rocket which in my experience can lead to people not running the tests as they take too long. Espeically in a Continuous Integration environment/build environment, the longer the tests take to run, the longer it tasks to get a build prepared.
My personal opinion is that I like to use a combination of mocking and actual db access in my unit tests, as I like to know that my code will run as expected all the way through to and from the db, to catch silly mistakes like SPs missing/errors (bordering between unit/integration/functionality tests). But where it's not so important, I use mocks.