Как могут поддельные внешние сервисы улучшить юнит-тесты?

Question

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

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

Мне нужно издеваться, чтобы принимать и возвращать реалистичные сообщения и ответы - иначе мои тесты не будут отражать реальное положение дел. Например, он должен выдавать правильные ошибки - и есть по крайней мере 7 различных способов, которыми он может потерпеть неудачу (между вами и мной это не очень хорошо продуманный внешний сервис). Поэтому, как минимум, я должен иметь хэш пар сообщение / ответ.

Таким образом, вместо уменьшения непредвиденных обстоятельств, насмешка вновь ввела его в другое место. На самом деле, как говорится, теперь у меня есть две проблемы: я должен быть уверен, что в моем хэше есть точное представление о том, как ведет себя внешняя служба. Но, безусловно, каноническим источником ответа объекта X на сообщение m является сам X. Все остальное рискованно и грязно.

Я сделал неправильный поворот? Как я могу устранить эту кажущуюся круглость?

РЕДАКТИРОВАТЬ Я пояснил, в чем, на мой взгляд, проблема в свете полезных комментариев Правосудия.

Answer 1

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

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

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

Суть, однако, в том, чтобы иметь что-то, в чем вы действительно уверены и которое вы полностью контролируете.

Answer 2

Убедитесь, что все, от чего зависит ваш класс, имеет интерфейс (в отличие от конкретной реализации), и тогда вы можете использовать JMock . Это значительно упростит ваше тестирование. Вы можете сделать что-то, например, сказать ему, чтобы он ожидал вызова метода X, возвращал определенное значение или генерировал исключение. Это действительно экономит время.

Answer 3

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