Где лучше всего создавать тестовые данные в TDD?

Question

Я использую интеграционные тесты NUnit.Я пытаюсь проверить, чтобы убедиться, что пользователь не может создать учетную запись с существующей электронной почтой.(test@example.com)

Мне нужно иметь тестовые данные в базе данных (учетная запись с электронной почтой test@example.com).

Я могу создать эту учетную запись в функции тестированияв сценарии sql (и запускайте его перед интеграционными тестами).

Где лучше создать эти тестовые данные?

Answer 1

Ни один из вариантов не является неправильным, но есть несколько способов расширить и укрепить вашу стратегию:

• Насмешка , которая идет рука об руку с TDD
• Генерация тестовых данных БД с помощью таких инструментов, как Sql Data GenG RedGate
• Создание подключаемых поставщиков данных (IoC / DI), где вы можете переключаться между тестированием и производством

Ни одно из этих решений не является взаимоисключающим. Я бы порекомендовал последний пункт, особенно (подключаемый провайдер), а затем выбор между имитацией объекта или ложным, но качественным тестированием данных в БД.

Answer 2

Ваш лучший выбор - изучить основы внедрения зависимостей и Mocking.Таким образом, вы можете поменять поставщиков данных с поставщиками поддельных данных и использовать данные, которые соответствуют вашим потребностям, для конкретного теста.

Если вы используете NHibernate или аналогичный, вы всегда можете воссоздать свою схему БД перед каждым тестом(крепление).

Answer 3

В ситуации, как вы описали, я бы предпочел создать учетную запись в тестовой функции.

Юнит-тест должен быть как можно более независимым. Кроме того, это помогает понять, что вы тестируете, если вы видите все данные, необходимые для теста, в одном месте.

Вот полностью составленный пример, который должен проиллюстрировать:

[Test]
public void Test_CannotCreateDuplicateEmail()
{
   // Arrange
   CreateAccount("test@example.com");   // OK

   // Act
   try
   {
      CreateAccount("test@example.com");

      // 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);
   }
}