我应该单元测试数据访问层吗？这是一个很好的做法，怎么做？

如果我具有例如称为UserProvider 类和业务逻辑的类UserBl数据访问层（NHibernate的），应予两个测试他们的方法SaveUser或GetUserById，或在DA层的任何其他公开的方法是从BL称为层。这是冗余还是常见做法？我应该单元测试数据访问层吗？这是一个很好的做法，怎么做？

它是常见的单元测试DA层，或属于整合测试域？在测试期间是否有更好的测试数据库或创建数据库数据？

任何帮助表示赞赏。

来源

2010-07-26 nemke

对每个图层甚至是DAL编写单元测试是一种很好的做法。

我不认为在实际分贝运行测试是一个好主意，你可能会毁了重要数据。我们曾经为其测试数据库的副本设置了足够的数据来运行测试。在我们的测试项目中，我们有一个带有测试设置的特殊web.config文件，比如ConnectionString到我们的测试数据库。

来源

2010-07-26 08:08:03 gillyb

有没有正确的答案，这取决于。有些人（例如Roy Osherove）表示您应该只测试具有条件逻辑（IF语句等）的代码，其中可能包含或不包含您的DAL。有些人（通常是TDD的人）会说你应该测试所有的东西，包括DAL，并且目标是100％的代码覆盖率。

个人我只测试它，如果它在具有逻辑，所以用测试了一些DAL方法和一些未结束。大多数情况下，你最终只会检查你的BL称你的DAL，这有一些好处，但我不认为有必要。我认为让端到端覆盖应用程序的集成测试更有意义，包括数据库，它涵盖了像GetUserById这样的东西。

无论哪种方式，你可能已经知道了，但要确保你的单元测试不碰一个实际的数据库。（这样做没有问题，但这是一个集成测试，而不是单元测试，因为它需要很长的时间并涉及复杂的设置，应该单独运行）。

来源

2010-07-26 08:17:26

这与我对DAL测试的看法非常相似。如果在那里有任何逻辑，并且你想确保它能够工作，那就为它编写单元测试。总的来说，充分利用您的时间和精力可以针对具有已知测试数据的真实数据库设置集成测试。 – 2010-07-26 21:19:53

而SQL不包含逻辑？ – 2010-07-26 23:36:22

@帕斯卡尔 - 以及我的SQL通常不会，不，但我并不是说你不应该测试它。但我不会将其作为DAL的一部分进行测试，它可能是单独的一组单元测试（可能使用不同的工具，可能是DBFit），也可能是集成测试的一部分。正如我所说，由于设置的复杂性，潜在的环境问题（需要本地数据库或网络）以及速度降低，我认为'代码'单元测试不应触及数据库。 – 2010-07-27 08:19:36

根据我的经验，自行测试每个图层很有帮助。整合并再次测试。集成测试通常不会测试所有方面。有时如果数据访问层（我不知道nHibernate）是生成代码还是某种通用代码，它看起来像是过度杀毒。但我不止一次看到系统测试带来了回报。

冗余吗？我认为这不是。

这是常见的做法吗？很难说。我会说不。我曾在一些项目中看到过它，但在我参与过的所有项目中都看不到它。经常依赖于团队/个人开发人员的时间/资源和心态。

在测试过程中是否有更好的测试数据库或创建数据库数据？这是一个完全不同的问题。无法轻松回答。取决于你的项目。创建一个新的很好，但有时会抛出不真实的错误（虽然错误）。它取决于您的项目（产品开发或专有开发）。通常在专有站点开发中，数据库会从某个地方迁移。因此，迁移数据肯定需要第二次测试。但这是在系统测试级别。

来源

2010-07-26 08:24:09 hol

单元测试DAL是值得的，因为提到的如果，如果使用相同的StoredProc用于插入&更新其值得了解插入的作品，随后调用更新前面和select返回它有逻辑在里面，例如而不是一个列表。在你的情况下，SaveUser方法可能会插入第一次，随后更新，它很高兴知道这是什么在单元测试阶段完成。

如果你使用像iBatis的框架或休眠状态，您可以实现的类型处理它的价值，确认处理程序的方式，是可以接受的您的基础数据库处理的值。

至于测试一个实际的数据库，如果你使用像Spring这样的框架，你可以利用事务的自动回滚支持数据库单元测试类，这样你可以运行你的测试并且数据库不会受到影响。有关信息，请参阅here。其他人可能提供类似的支持。

来源

2010-07-27 00:07:46 MadMurf

我应该单元测试数据访问层吗？这是一个很好的做法，怎么做？

回答

相关问题