Как бороться с текущими данными в тестовых методах?

Question

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

Проблема в том, что я должен учитывать исходное состояние данных и восстанавливать его после тестирования, даже в образце базы данных, чтобы сохранить данные для следующего теста.

public void DisableAndEnableAccount()
{
    var client = new GwIntegrationServiceSoapClient();

    string userName = "admin";
    Account account = client.GetAccountByUsername(userName);
    int accountID = account.Id;

    bool isActiveOrginalValue = account.IsActive;

    if (isActiveOrginalValue)
    {
        client.DisableAccount(accountID);
        account = client.GetAccountByUsername(userName);

        Assert.IsFalse(account.IsActive);

        client.EnableAccount(accountID);
        account = client.GetAccountByUsername(userName);

        Assert.IsTrue(account.IsActive);
    }
    else
    {
        client.EnableAccount(accountID);
        account = client.GetAccountByUsername(userName);

        Assert.IsTrue(account.IsActive);

        client.DisableAccount(accountID);
        account = client.GetAccountByUsername(userName);

        Assert.IsFalse(account.IsActive);
    }
}

Я думаю, что мой метод тестирования написан не очень хорошо. Есть идеи, как поступить с таким случаем?

Answer 1

Вы должны использовать тестовые данные (тестовые учетные записи пользователей) в своих тестах, а не реальные.(На самом деле, настоятельно рекомендуется использовать отдельную тестовую БД для ваших тестов, а не реальную живую производственную БД.) Тогда вы можете настроить ее любым способом, который вам нужен до начала теста.Кстати, рекомендуется выполнить настройку в отдельном методе setUp() (или в аннотации @Before в JUnit 4).

Обратите внимание, однако, что «классические» модульные тесты не должны зависеть от внешних объектов, таких какБД или файловая система: они должны сосредоточиться на тестировании одного модуля (класса, метода), изолированного от остального мира.Обычно это достигается с помощью внедрения зависимостей и насмешек , то есть сокрытия их за интерфейсами, так что в модульных тестах вы можете указатьфиктивная реализация, которая, например, не подключается к БД, просто проверяет сделанные ей вызовы и переданные параметры.

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

Answer 2

У вас всегда будут проблемы с восстановлением данных до исходного состояния с помощью этого метода. Как правило, решение состоит в том, чтобы избежать попыток сделать это, как отмечает @ Петер Тёрёк (я также почти полностью согласен с его постом).

Многие вещи могут пойти не так между различными этапами вашего теста: что, если интернет-соединение оборвется, и вы потеряете соединение с веб-службой? Что произойдет, если вы допустили ошибку в своем тестовом коде и нарушили действительные данные тестовой учетной записи?

Если абсолютно необходимо провести какое-то автоматическое тестирование с внешним веб-сервисом, я бы предложил договориться с владельцем сервиса о возможности автоматического сброса тестовых объектов или что-то в этом роде. Таким образом, вы можете сосредоточиться на том, чтобы ваши тесты действительно тестировали функциональность, а не беспокоиться о том, как вы вернете данные к тому, с чего они начинали.