在 TDD 中创建测试数据的最佳位置在哪里?
我使用 NUnit 集成测试。 我正在尝试测试以确保用户无法使用现有电子邮件创建帐户。 ([email protected])
我需要在数据库中有测试数据( [电子邮件受保护]电子邮件的帐户)。
我可以在测试函数或 sql 脚本中创建此帐户(并在集成测试之前运行它)。
创建此测试数据的更好位置在哪里?
I use NUnit integration tests.
I am trying to test to make sure that user can't create account with existing email. ([email protected])
I need to have test data in the database (account with [email protected] email).
I can create this account in the test function, or in the sql script (and run it before integration tests).
Where is the better place to create this test data?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
这两种选择都没有错,但有多种方法可以扩展和巩固您的策略:
这些解决方案都不是相互排斥的。我特别推荐最后一项(可插入提供程序),然后在对象模拟或人造但高质量的数据库测试数据之间进行选择。
Neither option is wrong but there are a number of ways to extend and solidify your strategy:
None of these solutions are mutually exclusive. I would recommend the last item especially (pluggable provider) and then a choice between object mocking or faux but quality db test data.
最好的选择是研究依赖注入和模拟框架。通过这种方式,您可以用模拟数据提供程序替换数据提供程序,并使用适合您特定测试需求的数据。
如果您使用 NHibernate 或类似的,您始终可以在每次测试(固定装置)之前重新创建数据库架构。
Your best bet is to look into Dependency Injection and Mocking frameworks. This way you can swap out data providers with mocked data providers and use the data that fits your needs for the specific test.
If you're using NHibernate or similar, you can always recreate your db schema before each test(fixture).
在您描述的情况下,我更愿意在测试功能中创建帐户。
单元测试应该尽可能独立。此外,如果您可以在一处查看测试所需的所有数据,则有助于了解您正在测试的内容。
这是一个完全虚构的示例,应该可以说明:
In a situation like you describe, I would prefer to create the account in the test function.
A unit test should be as self contained as possible. Also, it helps to be able to understand what you are testing, if you can see all the data required for the test in one place.
Here's a totally made up example that should illustrate: