【发布时间】：2010-01-25 18:32:55
【问题描述】：
我们正在尝试使用 Fitnesse 进行功能测试。我应该模拟依赖关系还是应该针对数据库进行测试？
这两种方法的优缺点是什么？
对数据库进行测试的整个问题是设置具有巨大依赖性的数据。如果我们模拟，那么它是真正的功能测试吗？
谢谢
【问题讨论】：
标签： testing mocking functional-testing fitnesse
【发布时间】：2010-01-25 18:32:55
【问题描述】：
我们有一套完整的端到端功能测试，可以在两种模式下运行：“InMemory”和“Database”，根据运行测试的配置决定测试使用的存储库。这有几个优点：
1) 它可以防止开发人员将大量功能构建到数据库中并保留在代码中。
2) 当“内存中”时，fitnesse 测试运行得非常非常快。允许测试非常非常快地失败……从而加快开发和敏捷性。当它们以 db 模式运行时，它们确实需要一些时间。
【讨论】：
我看到（至少）2 种类型的测试可以使用 FitNesse 完成：
旨在指定域逻辑或行为的测试（或示例）。这些我倾向于不与数据库访问一起使用，因为这对于测试的目的通常并不重要。
端到端（或几乎端到端）测试用作回归或冒烟测试。这些显然包括数据库功能。
包含数据库的好处是测试更能代表实际的生产系统，缺点是设置和管理数据库状态的额外成本。看看 DbFit，一组旨在帮助进行数据库设置和验证的固定装置。
【讨论】：
我宁愿在 NUnit 中隔离涉及数据库的集成测试。 您的功能测试不应该因为集成问题而失败。 我发现通过简单的单例传递对象状态比 DB 更舒服。
【讨论】：
我认为它应该针对数据库进行测试。因为当您使用 Fitnesse 进行功能测试时，您不应该使用模拟。将它与数据库一起使用以了解实际的数据库功能是否正常工作，因为您的数据库将拥有大量数据。
【讨论】：
-
谢谢。设置数据的痛苦呢？对每个测试用例来说都不是那么难。我们希望使用 CI 的这一部分。在 Fitnesse 中设置数据的难易程度如何？
我一直致力于为与数据库相关的东西创建一个不同的测试套件，这让我在进行其他功能测试时更有信心。 可以验证诸如业务规则、存储过程和一些基本但重要的表之类的东西，以确保它们在它们假设的位置并呈现正确的结果。如果这符合预期，那么您在前端看到的应该是进行功能测试的可靠环境
【讨论】：