去年夏天,我开发了一个基本的ASP.NET/SQL Server CRUD应用程序,单元测试是其中一个要求.当我尝试对数据库进行测试时遇到了一些麻烦.根据我的理解,单元测试应该是:
在开发数据库时,这些要求似乎彼此不一致.例如,我无法在不确定要插入的行的情况下测试Insert(),因此我需要先调用Delete().但是,如果他们还没有呢？然后我需要先调用Exists()函数.
我最终的解决方案涉及非常大的设置功能(yuck!)和一个空的测试用例,它将首先运行并指示设置运行没有问题.这是牺牲测试的独立性,同时保持他们的无国籍状态.
我找到的另一个解决方案是将函数调用包装在一个可以轻松回滚的事务中,比如Roy Osherove的XtUnit.这项工作,但它涉及另一个库,另一个依赖,并且对于手头的问题似乎有点太沉重的解决方案.
那么,在面对这种情况时,SO社区做了什么？
tgmdbm说:
您通常使用自己喜欢的自动单元测试框架来执行集成测试,这就是为什么有些人会感到困惑,但他们不遵循相同的规则.您可以参与许多课程的具体实施(因为它们已经过单元测试).您正在测试具体类如何与彼此以及与数据库交互.
因此,如果我正确地阅读此内容,则无法有效地对数据访问层进行单元测试.或者,数据访问层的"单元测试"是否涉及测试,例如,由类生成的SQL /命令,而不依赖于与数据库的实际交互？