Fitnesse-测试应该与数据库对话吗？
我们正在尝试使用 Fitnesse 进行功能测试。我应该模拟依赖关系还是应该针对数据库进行测试？
这两种方法的优点/缺点是什么？
针对数据库进行测试的整个问题是设置数据，这是巨大的依赖性。如果我们模拟，那么它是真正的功能测试吗？
谢谢
We are trying to use Fitnesse for our Functional test. Should i be mocking dependencies or should it be testing against the database?
What are the Pros/Cons of either of the approach?
The whole issue of testing against the DB is setting up data which is huge dependency. If we mock then is it real functional test?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我们有一整套端到端的功能测试，可以在fitnesse中以两种模式运行：“内存中”和“数据库”，根据运行测试的配置来决定测试使用的存储库。这有几个优点：
1) 它使开发人员无需将大量功能构建到数据库中并保留在代码中。
2）当“内存中”时，健身测试运行得非常非常快。允许测试非常非常快地失败......从而加快开发和敏捷性。当它们仅在数据库模式下运行时，它们确实需要一些时间。
We have a full set of end to end functional tests that run in fitnesse in two modes: "InMemory" and "Database", Depending on which configuration to run the tests in dictates which repositories the tests use. This has several advantages:
1) It keeps the developers from building a lot of functionality into the database and keeps in in the code.
2) When "In-Memory" the fitnesse tests run very very fast. Allowing the tests to fail very very fast...and thus speed up development and agility. When they run in db mode only they do take some time.
我看到（至少）有两种类型的测试可以使用 FitNesse 完成：
旨在指定域逻辑或行为的测试（或示例）。我倾向于不与数据库访问一起使用，因为这通常对测试的目的并不重要。
用作回归或冒烟测试的端到端（或接近端到端）测试。显然，这些包括数据库功能。
包含数据库的好处是测试更能代表实际生产系统，缺点是设置和管理数据库状态的额外成本。看一下 DbFit，这是一组旨在帮助数据库设置和验证的装置。
I see (at least) 2 types of tests that can be done with FitNesse:
Tests (or examples) intended to specify domain logic or behavior. These I tend not to use with database access as this is usually not important to the purpose of the test.
End-to-end (or nearly end-to-end) tests used as regression or smoke tests. These, obviously, include database functionality.
The benefit of including the DB is that the test is more representative of the actual production system, the drawback is the additional cost of setting up and managing database state. Look at DbFit, a set of fixtures designed to help with DB set-up and verification.
我宁愿在 NUnit 中隔离涉及数据库的集成测试。
您的功能测试不应该因为集成问题而失败。
我发现通过简单的单例来携带对象状态比通过数据库更舒服。
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进行功能测试时，你不应该使用mock。将其与数据库一起使用可以了解实际的数据库功能是否正常工作，因为您的数据库将拥有大量数据。
I think it should test against the database. Because as you are doing functional test with fitnesse, you shoudnt be using mock. Use it with database to know the actual database functionality working fine or not as your DB will have a huge data.
我一直致力于为数据库相关的东西创建一个不同的测试套件，这让我在进行其他功能测试时更有信心。
可以验证业务规则、存储过程和一些基本但重要的表等内容，以确保它们位于预期位置并呈现正确的结果。如果这符合预期，那么您在前端看到的应该是进行功能测试的可靠环境
I have worked on creating a different test suite for DB related stuff which gives me more confidence when I get into other functionality testing.
Things like business rules, stored procs and some basic but important tables can be validated to make sure they are where they suppose to be and rendering right results. If that's as expected then what you see on front end should be a solid environment to do functionality tests