Издевается ... а верификаторы?

Question

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

Позвольте мне немного пояснить: учитывая, что два компонента A и B и A используют B, тогда у нас есть определенный «восходящий контракт» для B и определенный «нисходящий контракт» для A. В основном это означает: если A использует B правильно и B ведет себя правильно, тогда оба контракта будут выполнены, и все будет работать правильно.

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

Однако мне сейчас интересно, есть ли способ проверить также и нисходящий контракт. На примере подключения к базе данных может быть заключен нисходящий контракт: необходимо подключиться к базе данных и убедиться, что соединение существует и работает, и ввести правильные SQL-запросы.

Кто-нибудь делает что-то подобное? Стоит ли это работать для более сложных контрактов? (Например, для подключения к базе данных может потребоваться анализатор SQL для полной проверки вызовов на уровне базы данных)

Привет, Тета

Answer 1

На самом деле это разница между макетами и заглушками - макеты точно это подтверждают (или, по крайней мере, могут это сделать - вы можете использовать макеты в качестве заглушек в большинстве фреймворков). По сути, mocks позволяет вам тестировать протокол , а не просто "если вы позвоните X, я дам вам Y". Каждый использованный мною фреймворк позволяет легко проверять такие вещи, как «все эти звонки были сделаны» и «эти звонки происходили в определенном порядке».

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

Answer 2

Кто-нибудь делает это?

Да, я иногда использую насмешки для проверки "нисходящих контрактов".

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

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

---

Стоит ли работать?

Это зависит от того, насколько глубоко вы хотите, чтобы ваши испытания были, позвольте мне привести несколько примеров различной «глубины»:

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

Вывод:

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