我应该对数据访问层进行单元测试吗？这是一个好的做法吗？如何做？
如果我有数据访问层（nHibernate），例如一个名为 UserProvider 的类 和业务逻辑类 UserBl，我应该测试它们的方法 SaveUser 或 GetUserById，还是 DA 层中从 BL 层调用的任何其他公共方法。这是一种冗余还是一种常见做法？
单元测试DA层是常见的，还是属于集成测试领域？ 是拥有测试数据库更好，还是在测试期间创建数据库数据更好？
任何帮助表示赞赏。
If I'm having Data Access Layer (nHibernate) for example a class called UserProvider
and a Business Logic class UserBl, should I both test their methods SaveUser or GetUserById, or any other public method in DA layer which is called from BL layer. Is this a redundancy or a common practice to do?
Is it common to unit test DA layer, or that belongs to Integration test domain?
Is it better to have test database, or create database data during test?
Any help is appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这个问题没有正确的答案，这取决于情况。有些人（例如 Roy Osherove）说您应该只测试具有条件逻辑（IF 语句等）的代码，其中可能包括也可能不包括您的 DAL。有些人（通常是那些进行 TDD 的人）会说你应该测试所有内容，包括 DAL，并以 100% 的代码覆盖率为目标。
就我个人而言，我只测试它是否有逻辑，所以最终测试了一些 DAL 方法，而另一些则没有。大多数时候，您只是最终检查您的 BL 是否调用了 DAL，这有一些优点，但我认为没有必要。我认为进行涵盖应用程序端到端的集成测试更有意义，其中包括数据库，其中涵盖了 GetUserById 之类的内容。
无论哪种方式，您可能已经知道这一点，但请确保您的单元测试不会接触实际的数据库。 （这样做没问题，但这是集成测试而不是单元测试，因为它需要更长的时间并且涉及复杂的设置，并且应该单独运行）。
There's no right answer to this, it really depends. Some people (e.g Roy Osherove) say you should only test code which has conditional logic (IF statements etc), which may or may not include your DAL. Some people (often those doing TDD) will say you should test everything, including the DAL, and aim for 100% code coverage.
Personally I only test it if it has logic in, so end up with some DAL methods tested and some not. Most of the time you just end up checking that your BL calls your DAL, which has some merit but I don't find necessary. I think it makes more sense to have integration tests which cover the app end-to-end, including the database, which covers things like GetUserById.
Either way, and you probably know this already, but make sure your unit tests don't touch an actual database. (No problem doing this, but that's an integration test not a unit test, as it takes a lot longer and involves complex setup, and should be run separately).
为每一层（甚至 DAL）编写单元测试是一个很好的做法。
我认为在真实数据库上运行测试不是一个好主意，您可能会破坏重要数据。我们曾经为测试设置数据库的副本，其中只有足够的数据来运行测试。
在我们的测试项目中，我们有一个特殊的 web.config 文件，其中包含测试设置，例如测试数据库的 ConnectionString。
It is a good practice to write unit test for every layer, even the DAL.
I don't think running tests on the real db is a good idea, you might ruin important data. We used to set up a copy of the db for tests with just enough data in it to run tests on.
In our test project we had a special web.config file with test settings, like a ConnectionString to our test db.
根据我的经验，单独测试每一层是有帮助的。集成它并再次测试。集成测试通常不会测试所有方面。有时，如果数据访问层（我不知道 nHibernate）是生成的代码或某种通用代码，那么它看起来有点矫枉过正。但我不止一次地看到系统测试是有回报的。
是冗余吗？我认为并非如此。
这是常见做法吗？很难说。我会说不。我在一些项目中看到过这种情况，但并非在我参与的所有项目中都看到过。通常取决于团队/个人开发人员的时间/资源和心态。
是拥有测试数据库更好，还是在测试期间创建数据库数据更好？这是一个完全不同的问题。无法轻易回答。取决于你的项目。创建一个新的固然很好，但有时会引发不真实的错误（尽管是错误）。这取决于您的项目（产品开发或专有开发）。通常，在专有的现场开发中，数据库会从某个地方迁移到其中。因此，肯定需要对迁移的数据进行第二次测试。但这只是系统测试级别。
In my experience it was helpful to test each layer on its own. Integrating it and test again. Integration test normally does not test all aspects. Sometimes if the Data Access Layer (I don't know nHibernate) is generated code or sort of generic code it looks like overkill. But I have seen it more than once that systematic testing pays off.
Is it redundancy? In my opinion it is not.
Is it common practice? Hard to tell. I would say no. I have seen it in some projects but not in all projects I worked in. Was often dependend on time/resources and mentality of the team / individiual developer.
Is it better to have test database, or create database data during test? This is quite a different question. Cannot be answered easily. Depends on your project. Create a new one is good but sometimes throws up unreal bugs (although bugs). It is depending on your project (product development or a proprietary development). Usually in an proprietary on site development a database gets migrated into from somewhere. So a second test is definitely needed with the migrated data. But this is rather at a system test level.
如前所述，如果其中存在逻辑，例如如果使用相同的 StoredProc 进行插入和存储，则对 DAL 进行单元测试是值得的。更新它的价值，知道插入有效，后续调用更新前一个调用，选择返回它而不是列表。在您的情况下，SaveUser方法可能会第一次插入并随后更新，很高兴知道这是在单元测试阶段所做的事情。
如果您使用像 iBatis 或 Hibernate 这样的框架，您可以在其中实现类型处理程序，那么值得确认处理程序以底层数据库可接受的方式处理值。
至于针对实际数据库进行测试，如果您使用像 Spring 这样的框架，您可以利用支持的数据库单元测试类和事务自动回滚，以便您运行测试并且之后数据库不受影响。请参阅此处了解信息。其他人可能会提供类似的支持。
Unit testing the DAL is worth it as mentioned if there is logic in there, for example if using the same StoredProc for insert & update its worth knowing that an insert works, a subsequent call updates the previous and a select returns it and not a list. In your case SaveUser method probably inserts first time around and subsequently updates, its nice to know that this is whats being done at unit test stage.
If you're using a framework like iBatis or Hibernate where you can implement typehandlers its worth confirming that the handlers handle values in a way that's acceptable to your underlying DB.
As for testing against an actual DB if you use a framework like Spring you can avail of the supported database unit test classes with auto rollback of transactions so you run your tests and the DB is unaffected afterwards. See here for information. Others probably offer similiar support.