在 TDD 中创建测试数据的最佳位置在哪里?

发布于 2024-10-02 23:05:10 字数 413 浏览 3 评论 0原文

我使用 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

一袭水袖舞倾城 2024-10-09 23:05:10

这两种选择都没有错,但有多种方法可以扩展和巩固您的策略:

这些解决方案都不是相互排斥的。我特别推荐最后一项(可插入提供程序),然后在对象模拟或人造但高质量的数据库测试数据之间进行选择。

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.

数理化全能战士 2024-10-09 23:05:10

最好的选择是研究依赖注入和模拟框架。通过这种方式,您可以用模拟数据提供程序替换数据提供程序,并使用适合您特定测试需求的数据。

如果您使用 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).

甜警司 2024-10-09 23:05:10

在您描述的情况下,我更愿意在测试功能中创建帐户。

单元测试应该尽可能独立。此外,如果您可以在一处查看测试所需的所有数据,则有助于了解您正在测试的内容。

这是一个完全虚构的示例,应该可以说明:

[Test]
public void Test_CannotCreateDuplicateEmail()
{
   // Arrange
   CreateAccount("[email protected]");   // OK

   // Act
   try
   {
      CreateAccount("[email protected]");

      // If control arrives here, then the test has failed.
      Assert.Fail();
   }

   // Assert
   catch(AccountException ex)
   {
        // Assert that the correct exception has been thrown.
        Assert.AreEqual("Failed", ex.Message);
   }
}

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:

[Test]
public void Test_CannotCreateDuplicateEmail()
{
   // Arrange
   CreateAccount("[email protected]");   // OK

   // Act
   try
   {
      CreateAccount("[email protected]");

      // If control arrives here, then the test has failed.
      Assert.Fail();
   }

   // Assert
   catch(AccountException ex)
   {
        // Assert that the correct exception has been thrown.
        Assert.AreEqual("Failed", ex.Message);
   }
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文