其中许多直接连接到sql Server数据库.数据库由代码生成器生成,代码生成器在许多方面创建数据库.生成数据库很慢而且很麻烦.
这有以下问题：
>测试清理db,这意味着我们必须为测试维护一个单独的db,而另一个使用该应用程序.现在的过程是在运行测试和运行应用程序之间进行更改时更改数据库.
>每个分支都需要拥有自己的数据库,因为每个数据库中的数据库模型可能不同(这意味着每个分支有2个数据库,步骤1)
>这很慢
>必须存在sql Server和db的安装才能运行测试
我希望现有的测试不依赖于这样的安装,如果可能的话运行得更快,而不必通过代码生成器,杂耍连接字符串等来处理维护数据库.
我试图尽快实现这一点,因为重写测试不在预算范围内.我已经引入了模拟来帮助新测试减少对数据库的依赖,我现在的问题是现有的测试.
我的第一个问题是将我们的基本单元测试类更改为连接到sqlite数据库,该数据库将由代码生成器创建,该代码生成器已生成主数据库而不是sql Server数据库.然后可以删除sqlite并在每次运行之间重新复制到测试文件夹.这本来很快,不需要2个sql Server数据库,事实上如果只是运行测试,则不需要sql Server安装.
我的问题是生成的代码使用了sqlite中没有包含的许多概念; T-sql,sql Server特定语法,模式,存储过程和嵌入式clr程序集.
然后我尝试了sql Server CE 4,它有许多与sqlite相同的限制.
除了重写代码以与sqlite(或CE)兼容,重写现有测试或我们维护2 seperatedb的系统之外,还有其他可用的替代方案吗？
编辑：将单元测试更改为功能测试,澄清了一些事情.把一些东西放大胆.
我同意这些测试不是适当的单元测试.我同意嘲笑在这里会很好.我想要做的是尝试解决我面临的混乱局面.
解决方法
我不是.NET开发人员所以我不能推荐最好的Mocking框架/工具,但也许是this question will point you in the right direction.
为什么单元测试不应该访问资源：
你会想要以不同的方式看待这个问题.您没有任何测试数据库本身的愿望,因为您必须假设您正在使用的数据库产品正常工作.因此,没有必要测试“$dao-> save()”实际插入记录.您可能感兴趣的是在完成某些其他操作时是否正在调用save()方法,或者您的DAO是否生成了正确的INSERT语句.
如果你必须在单元测试中进行数据库调用,因为你不能模拟进行数据库调用的对象,你需要重构.
肥皂盒时间：
这就是测试驱动开发如此有益的原因.从一开始就强调要保持脱钩和隔离,从而带来更好的整体设计,灵活性和可测试性.
