我们正在尝试使用 Fitnesse 进行功能测试。我应该模拟依赖关系还是应该针对数据库进行测试?
这两种方法的优点/缺点是什么?
针对数据库进行测试的整个问题是设置具有巨大依赖性的数据。如果我们模拟,那么它是真正的功能测试吗?
谢谢
我们正在尝试使用 Fitnesse 进行功能测试。我应该模拟依赖关系还是应该针对数据库进行测试?
这两种方法的优点/缺点是什么?
针对数据库进行测试的整个问题是设置具有巨大依赖性的数据。如果我们模拟,那么它是真正的功能测试吗?
谢谢
我们有一套完整的端到端功能测试,可以在两种模式下运行:“InMemory”和“Database”,根据运行测试的配置决定测试使用的存储库。这有几个优点:
1)它使开发人员无法将大量功能构建到数据库中并保留在代码中。
2) 当“内存中”时,fitnesse 测试运行得非常非常快。允许测试非常非常快地失败……从而加快开发和敏捷性。当它们以 db 模式运行时,它们确实需要一些时间。
我看到(至少)2 种类型的测试可以用 FitNesse 完成:
旨在指定域逻辑或行为的测试(或示例)。这些我倾向于不与数据库访问一起使用,因为这通常对测试的目的并不重要。
用作回归或冒烟测试的端到端(或几乎端到端)测试。显然,这些包括数据库功能。
包含数据库的好处是测试更能代表实际的生产系统,缺点是设置和管理数据库状态的额外成本。看看 DbFit,一组旨在帮助进行 DB 设置和验证的夹具。
I'd rather isolate the integration tests involving the DB in NUnit. Your fonctional tests should not fail because to integration issues. I've found more comfortable to carry object states through simple singletons than DB.
我一直致力于为与数据库相关的东西创建一个不同的测试套件,这让我在进行其他功能测试时更有信心。可以验证诸如业务规则、存储过程和一些基本但重要的表之类的东西,以确保它们在它们假设的位置并呈现正确的结果。如果这与预期的一样,那么您在前端看到的应该是进行功能测试的可靠环境
我认为它应该针对数据库进行测试。因为当您使用 Fitnesse 进行功能测试时,您不应该使用模拟。将它与数据库一起使用以了解实际的数据库功能是否正常工作,因为您的数据库将拥有大量数据。