问我应该单元测试数据访问层吗？这是一个好的实践吗?怎么做？

EN

这个问题没有正确的答案，这真的要看情况。有些人(例如Roy Osherove)说你应该只测试有条件逻辑(IF语句等)的代码，这可能包括也可能不包括你的DAL。有些人(通常是那些做TDD的人)会说，你应该测试一切，包括DAL，并以100%的代码覆盖率为目标。

就我个人而言，我只在它有逻辑的时候才测试它，所以最终测试了一些DAL方法，而另一些则没有。大多数时候，你只是检查你的BL是否调用了你的DAL，这有一些优点，但我认为没有必要。我认为更有意义的是让集成测试涵盖端到端的应用程序，包括数据库，它涵盖了GetUserById之类的东西。

无论哪种方式，您可能已经知道这一点，但请确保您的单元测试不会接触到实际的数据库。(这样做没有问题，但这是一个集成测试而不是单元测试，因为它需要更长的时间并且涉及复杂的设置，并且应该单独运行)。

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

我不认为在真正的数据库上运行测试是一个好主意，你可能会破坏重要的数据。我们过去常常为测试设置一个db副本，其中只包含运行测试所需的数据。在我们的测试项目中，我们有一个带有测试设置的特殊web.config文件，就像我们的测试数据库的ConnectionString。

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

是冗余吗？在我看来，它不是。

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

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