我使用很多Web应用程序,这些应用程序由后端不同复杂程度的数据库驱动.通常,存在与业务和表示逻辑分离的ORM层.这使得对业务逻辑的单元测试相当简单; 事物可以在离散模块中实现,测试所需的任何数据都可以通过对象模拟来伪造.
但是测试ORM和数据库本身一直充满了问题和妥协.
多年来,我尝试了一些策略,其中没有一个完全满足我.
使用已知数据加载测试数据库.针对ORM运行测试并确认正确的数据返回.这里的缺点是您的测试数据库必须跟上应用程序数据库中的任何模式更改,并且可能会不同步.它还依赖于人工数据,并且可能不会暴露由于愚蠢的用户输入而发生的错误.最后,如果测试数据库很小,它将不会显示缺失索引等低效率.(好吧,最后一个不是真的应该使用单元测试,但它没有受到伤害.)
加载生产数据库的副本并对其进行测试.这里的问题是你可能不知道在任何给定时间生产数据库中有什么; 如果数据随时间变化,您的测试可能需要重写.
有些人指出,这两种策略都依赖于特定的数据,单元测试应该只测试功能.为此,我见过建议:
您使用了哪些策略来测试数据库驱动的应用程序？什么对你有用？
去年夏天,我开发了一个基本的ASP.NET/SQL Server CRUD应用程序,单元测试是其中一个要求.当我尝试对数据库进行测试时遇到了一些麻烦.根据我的理解,单元测试应该是:
在开发数据库时,这些要求似乎彼此不一致.例如,我无法在不确定要插入的行的情况下测试Insert(),因此我需要先调用Delete().但是,如果他们还没有呢？然后我需要先调用Exists()函数.
我最终的解决方案涉及非常大的设置功能(yuck!)和一个空的测试用例,它将首先运行并指示设置运行没有问题.这是牺牲测试的独立性,同时保持他们的无国籍状态.
我找到的另一个解决方案是将函数调用包装在一个可以轻松回滚的事务中,比如Roy Osherove的XtUnit.这项工作,但它涉及另一个库,另一个依赖,并且对于手头的问题似乎有点太沉重的解决方案.
那么,在面对这种情况时,SO社区做了什么？
tgmdbm说:
您通常使用自己喜欢的自动单元测试框架来执行集成测试,这就是为什么有些人会感到困惑,但他们不遵循相同的规则.您可以参与许多课程的具体实施(因为它们已经过单元测试).您正在测试具体类如何与彼此以及与数据库交互.
因此,如果我正确地阅读此内容,则无法有效地对数据访问层进行单元测试.或者,数据访问层的"单元测试"是否涉及测试,例如,由类生成的SQL /命令,而不依赖于与数据库的实际交互？
我在寻找数据库开发的单元测试框架.我目前正在为SQL Server 2000,2005和2008开发.你知道任何具有与JUnit和NUnit类似功能的好框架吗？
也许最好问一下,你用什么来对你的存储过程和用户定义的函数进行单元测试？