我使用很多Web应用程序,这些应用程序由后端不同复杂程度的数据库驱动.通常,存在与业务和表示逻辑分离的ORM层.这使得对业务逻辑的单元测试相当简单; 事物可以在离散模块中实现,测试所需的任何数据都可以通过对象模拟来伪造.
但是测试ORM和数据库本身一直充满了问题和妥协.
多年来,我尝试了一些策略,其中没有一个完全满足我.
使用已知数据加载测试数据库.针对ORM运行测试并确认正确的数据返回.这里的缺点是您的测试数据库必须跟上应用程序数据库中的任何模式更改,并且可能会不同步.它还依赖于人工数据,并且可能不会暴露由于愚蠢的用户输入而发生的错误.最后,如果测试数据库很小,它将不会显示缺失索引等低效率.(好吧,最后一个不是真的应该使用单元测试,但它没有受到伤害.)
加载生产数据库的副本并对其进行测试.这里的问题是你可能不知道在任何给定时间生产数据库中有什么; 如果数据随时间变化,您的测试可能需要重写.
有些人指出,这两种策略都依赖于特定的数据,单元测试应该只测试功能.为此,我见过建议:
您使用了哪些策略来测试数据库驱动的应用程序？什么对你有用？
PHPUnit自己的手册有一些尚未写的部分,名为"操作"和"数据库测试最佳实践".
用于测试数据库的最佳实践是什么PHPUnit,特别是在MySQL？
只是把这个出来进行辩论.
我得到了单元测试.有时感觉很费时间,但我都是为了好处.
我使用IoC进行了包含存储库层和服务层的应用程序设置,并且我已经对这些方法进行了单元测试.
现在我知道隔离我的单元测试方法的好处,因此几乎没有依赖于其他方法.
我得到的问题是这个.如果我只通过我的服务层方法访问我的存储库方法,那么只测试服务层不够好吗？我正在测试测试数据库.
难道它不被认为是你只需要测试你的公共方法的想法的延伸吗？也许我只是想跳过一些测试;)