Fitnesse-应该测试与数据库交谈吗？

Question

我们正在尝试使用Fitnesse进行功能测试。我应该嘲笑依赖项还是应该针对数据库进行测试？

这两种方法的优点/缺点是什么？

针对数据库进行测试的整个问题是设置非常依赖的数据。如果我们嘲笑那么它是真正的功能测试吗？

谢谢

Answer 1

我们有两套完整的端到端功能测试，以两种模式运行在fitnesse中：“InMemory”和“Database”，具体取决于运行测试的配置，指示测试使用哪些存储库。这有几个好处：

1）它使开发人员不会在数据库中构建大量功能并保留在代码中。

2）当“In-Memory”中的fitnesse测试运行得非常快。允许测试非常快速地失败...从而加快开发和敏捷性。当它们以db模式运行时，它们确实需要一些时间。

Answer 2

我看到（至少）可以用FitNesse完成的两种类型的测试：

• 用于指定域逻辑或行为的测试（或示例）。这些我倾向于不与数据库访问一起使用，因为这对于测试的目的通常并不重要。

• 用作回归或烟雾测试的端到端（或接近端到端）测试。显然，这些包括数据库功能。

包含数据库的好处是测试更能代表实际的生产系统，缺点是设置和管理数据库状态的额外成本。查看DbFit，这是一套旨在帮助进行数据库设置和验证的灯具。

Answer 3

我宁愿在NUnit中隔离涉及DB的集成测试。 您的功能测试不应该因为集成问题而失败。 我发现通过简单的单身人士比DB更容易携带物体状态。

Answer 4

我认为它应该针对数据库进行测试。因为当你使用fitnesse进行功能测试时，你应该使用mock。与数据库一起使用可以了解实际的数据库功能是否正常，因为您的数据库将拥有大量数据。

Answer 5

我一直致力于为数据库相关的东西创建一个不同的测试套件，这让我在进入其他功能测试时更有信心。 可以验证业务规则，存储过程和一些基本但重要的表格，以确保它们是他们想要的位置并呈现正确的结果。如果这是预期的那么你在前端看到的应该是一个可靠的环境来进行功能测试