我应该单元测试数据访问层吗?这是一个好的做法,如何做到这一点?

这个问题没有正确的答案,这要看情况了。有些人(例如 Roy Osherove )假设您应该只测试具有条件逻辑(IF语句等)的代码,条件逻辑可能包含也可能不包含您的DAL。有些人(通常是那些做TDD的人)会说你应该测试所有的东西,包括DAL,并且目标是100%的代码覆盖率。

就我个人而言,我只测试它,如果它有逻辑,所以最后一些DAL方法测试和一些没有。大多数情况下,你只是结束检查你的BL调用你的DAL,这有一些优点,但我觉得没有必要。我认为更合理的做法是让集成测试覆盖应用程序的端到端,包括数据库,其中包括GetUserById之类的内容。

不管怎样,您可能已经知道了这一点,但是请确保您的单元测试不涉及实际的数据库。(这样做没问题,但这是一个集成测试而不是单元测试,因为它需要更长的时间和复杂的设置,应该单独运行)。

为每一层编写单元测试是一个很好的实践,甚至是DAL。

我不认为在真正的数据库上运行测试是个好主意,你可能会破坏重要的数据。我们曾经为测试设置一个数据库副本,其中只有足够的数据来运行测试。 在我们的测试项目中,我们有一个特殊的web.config文件带有测试设置的文件,比如测试数据库的ConnectionString。

根据我的经验,单独测试每一层是很有帮助的。整合并再次测试。集成测试通常不会测试所有方面。有时,如果数据访问层(我不知道nHibernate)是生成的代码或某种泛型代码,它看起来像是过度杀戮。但我不止一次地看到,系统测试是有回报的。

是冗余吗?在我看来不是。

这是惯例吗?很难说。我会说不。我在一些项目中看到过,但不是在我工作过的所有项目中都看到过。通常依赖于团队/个人开发人员的时间/资源和心态。

是有测试数据库更好,还是在测试期间创建数据库数据更好?这是一个完全不同的问题。不容易回答。取决于你的项目。创建一个新的是好的,但有时会抛出不真实的错误(虽然错误)。这取决于您的项目(产品开发或专有开发)。通常在专有的现场开发中,数据库会从某个地方迁移到其中。因此,迁移的数据肯定需要进行第二次测试。但这只是一个系统测试级别。

如前所述,如果DAL中有逻辑,那么单元测试DAL是值得的,例如,如果使用相同的StoredProc进行insert&update,那么在知道insert工作的情况下,后面的调用将更新前面的调用,select将返回它而不是列表。对你来说 保存用户 方法可能是第一次插入,然后更新,很高兴知道这是单元测试阶段正在做的事情。

如果您使用的是iBatis或Hibernate这样的框架,您可以在其中实现typehandlers,那么有必要确认处理程序以底层DB可以接受的方式处理值。

至于针对实际数据库的测试,如果您使用Spring这样的框架,那么您可以利用支持的数据库单元测试类,并自动回滚事务,这样您就可以运行测试,并且数据库随后不会受到影响。看到了吗 here 供参考。其他人可能会提供类似的支持。