单元测试业务逻辑层
我开始在我们公司引入正式的单元测试，因为我们的项目变得越来越大，并且在这个项目上另一个人将帮助我。所以我需要确保他所做的事情不会破坏一切，反之亦然。
我也想介绍一个 CI 服务器，但这将是其他问题的主题。现在的问题是：我目前正在阅读“单元测试的艺术”（这是一本建议的杰作！），作者强调的是单元测试与集成测试不同。这对我来说很清楚，如果我理解得很好，业务逻辑单元测试应该避免依赖数据库连接等。首先：我说得对吗？
那么，假设我是对的（即，当我对 BLL 进行单元测试时，我应该存根数据库），我将如何做？我读过有一些用于数据库模拟的框架。我应该使用其中之一吗？你用哪个？
下一个问题：您真的认为这是正确的做法吗？我的意思是：在我的项目中，BL 通过实体框架与数据库交互。因此，例如，当调用我的 BLL 中的“UpdateItem”方法时，它会执行某些操作，然后保存 ObjectContext。这个 ObjectContext 是我需要在 BL 中删除的实体框架依赖项。但我应该用这种方法测试什么？我真的无法理解在不一起测试 DAL 的情况下对 BL 层进行单元测试...你能给我一些例子吗？
非常感谢您的努力！
马可
I'm starting to introduce Formal Unit Testing in our company as we are having a project that's becoming bigger and bigger and on this project another guy is going to help me. So I need to be sure that what he does doesn't break up all and vice-versa.
I'd like to introduce a CI server too, but this will be the topic of other questions. Now the question is: I'm currently reading "The Art Of Unit Testing" (that's a suggested masterpiece!) and what the author underlines is that Unit Testing is different from Integration Testing. That's clear for me and, if I understood well, Business Logic unit testing should avoid to be dependent on database connections and so on. First of all: am I right?
So, supposing that I'm right (i.e. when I unit test my BLL I should stub the database), how will I do it? I've read that there are some framework for db mocking. Should I use one of these? Which do you use?
Next question: do you really think this is a correct way to do? I mean: in my project the BL interfaces with database through Entity Framework. So, for example, when the method "UpdateItem" in my BLL is called, it does something and then saves the ObjectContext. This ObjectContext is the Entity Framework dependency I need to remove in my BL. But what should I test in such a method? I really can't understand unit testing the BL layer without testing the DAL together... Can you give me some example?
Thanks a lot for your efforts!
Marco
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，
您是对的。
我建议您：
单元测试和集成测试之间的主要区别是：
* 单元测试速度快，不需要任何配置
* 集成测试可能很慢并且需要正确的配置（应该设置数据库并且应该有一个正确的连接字符串指向它）。
我认为这很好，因为它允许您在更改代码时经常运行业务单元测试。这很重要，因为您会得到非常快的反馈（通常在 1-2 秒内），表明您所做的更改没有破坏任何内容。
有时，您可以运行集成测试（这将需要更长的时间）来验证数据库是否仍然正常工作。
另外，我建议您阅读您提到的那本书。它认为这是有关该主题的非常重要的信息来源。
Yes,
You are right about that.
I recommend that you:
The main differences between unit tests and integration tests are:
* unit tests are fast and don't need any configuration
* integration tests may be slow and require proper configuration (a database should be set up and there should be a proper connection string pointing to it).
I think this is good because it allows you to run the business unit tests very often as you make changes to your code. This is important, because you get very fast feedback (usually within 1-2 seconds) that the changes you made didn't break anything.
Once in a while, you can run the integration tests (that will take longer) to validate that the DB still works correctly.
Also, I suggest you read the book that you mentioned. It think it is a very important source of information on this topic.
存根数据库是一项艰巨的任务，我认为不值得。我更喜欢有一个特殊的数据库副本，其中包含精心准备的适合单元测试的数据。
测试可以在测试结束时回滚的事务中运行。这样，单元测试数据库就不会被测试修改，并始终保持在已知状态。
我在使用事务进行单元测试中写了相关内容在我的博客上。示例代码适用于 linq-to-sql，但相同的方法也适用于实体框架。
Stubbing the database is a huge task, that I don't think is worth it. I prefer having a special database copy, with carefully prepared data that is suitable the unit tests.
The tests can be run within a transaction that is rolled back at the end of the test. That way, the unit test database is never modified by the tests and always kept in a known state.
I wrote about it in Using Transactions for Unit Tests on my blog. The sample code there is for linq-to-sql, but the same approach works for entity framework as well.