Интеграционное тестирование: правильно ли я делаю? - PullRequest
Новая
       11

Интеграционное тестирование: правильно ли я делаю?

7 голосов
/ 21 июня 2011

Вот интеграционный тест, который я написал для класса, взаимодействующего с базой данных: 

[Test]
public void SaveUser()
{
    // Arrange
    var user = new User();
    // Set a bunch of properties of the above User object

    // Act
    var usersCountPreSave = repository.SearchSubscribersByUsername(user.Username).Count();
    repository.Save(user);
    var usersCountPostSave = repository.SearchSubscribersByUsername(user.Username).Count();

    // Assert
    Assert.AreEqual(userCountPreSave + 1, userCountPostSave);
}

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

Хорошо, как я написал код до сих пор, или есть лучший способ?

Ответы [ 4 ]

8 голосов
/ 21 июня 2011

У вас проблема с тестом.Когда вы проверяете, что данные сохраняются в базе данных, вы должны проверять, что они находятся в базе данных, а не в том, что хранилище говорит, что оно находится в базе данных.тогда вы не сможете проверить эту функцию, спросив, правильно ли она это сделала.Это равносильно тому, чтобы сказать кому-то: «Ты сделал это правильно?»Они скажут «да».

Представьте, что хранилище никогда не фиксируется.Ваш тест пройдет успешно, но данные не будут в базе данных.

Итак, я бы сделал, чтобы открыть соединение (чистый SQL) с базой данных и проверить, что данные были сохраненыправильно.Вам нужно только выбрать количество (*) до и после, чтобы убедиться, что пользователь был сохранен.Если вы сделаете это, вы также можете избежать использования SearchSubscribeersByUsername.

Если вы тестируете функциональность хранилища, вы не можете доверять хранилищу по определению.

2 голосов
/ 21 июня 2011

Чтобы выполнить модульное тестирование чего-то вроде функции «Сохранить», вам определенно понадобится надежный канал для проверки результата операции. Если вы доверяете SearchSubscribersByUsername (поскольку вы уже выполнили некоторые модульные тесты для этой функции самостоятельно), вы можете использовать ее здесь.

Если вы не доверяете SearchSubscribersByUsername и думаете, что ваш модульный тест также может прерваться из-за ошибки в этой функции (а не в Save), вам следует подумать о другом канале (возможно, вы возможность сделать обход доступа SQL к вашей БД, чтобы проверить результат Save, который может быть проще, чем реализация SearchSubscribersByUsername)? Однако, не переопределяйте SearchSubscribersByUsername снова, это будет бессмысленно. В любом случае вам понадобится как минимум некоторая другая функция, которой вы можете доверять.

1 голос
/ 21 июня 2011

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

Я бы все-таки построил тесты, ориентированные на отдельные методы.Поэтому, тестируя Save (), я вполне могу использовать возможности Search (), но я сосредоточен на крайних случаях Save ().Я создаю тесты, которые имеют дело с дублирующими вставками или неверными входными данными.Затем позже я собрал целый ряд тестов Search (), которые имеют дело с крайними случаями Search ().

Теперь одним из возможных способов мышления является то, что Save и Search имеют некоторую общность, ошибка в Search может маскироватьсяошибка в Save.Представьте, например, если у вас там был слой кеширования.Поэтому, возможно, альтернативный подход заключается в использовании другого механизма проверки.Например, прямой вызов JDBC к базе данных или альтернативное введение насмешливых слоев в какой-то момент вашей инфраструктуры.При построении сложных интегрированных систем такая проверка «задней двери» может оказаться необходимой.

0 голосов
/ 21 июня 2011

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

...