Как выполнить модульное тестирование почтового клиента - PullRequest
3 голосов
/ 08 октября 2009

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

Есть ли у кого-нибудь идеи о том, как протестировать такого рода приложение, где оно опирается на внешние факторы при разработке?

EDIT:

Чтобы добавить некоторые детали: я работаю над библиотекой почтового клиента C ++ более высокого уровня для моего приложения, которая использует libEtPan, библиотеку C, чтобы фактически обрабатывать детали подключения к почтовому серверу и взаимодействия с ним.

Ответы [ 5 ]

7 голосов
/ 08 октября 2009

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

Чтобы сделать это эффективно, вам нужен интерфейс для общения с вашим почтовым сервером. Для тестирования реализация является макетом объекта. Для развертывания вы заменяете это реализацией, которая взаимодействует напрямую с почтовым сервером.

См. ТАК * вопрос для фреймворков C ++.

1 голос
/ 08 октября 2009

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

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

Я бы попытался написать это, чтобы оно могло работать, по крайней мере, следующими двумя способами: во-первых, он подключается к локальному серверу электронной почты, который вы можете настроить и настроить по своему усмотрению. В Java я использую Dumpster , но я уверен, что подобное существует для C ++. Вторым было бы подключиться по крайней мере к одному локальному почтовому серверу, который вы можете написать. Тот, который вы можете разбрызгивать сколько угодно (так, чтобы он не был реальным или не использовался совместно разработчиками) и запускать тот же набор тестов против этого. Причина в том, что разработчики SMTP-серверов ненавидят всех, и вы захотите проверить, работает ли ваша заглушка так же, как настоящая. Это я вижу как эквивалент Одна база данных на разработчика .

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

1) Может быть, вы могли бы сделать это как раз во время цикла CI, поэтому затем поделитесь одним набором серверов электронной почты между всеми разработчиками, и при локальном запуске просто используется C ++ Dumpster.

1 голос
/ 08 октября 2009

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

Кстати: если вы используете «реальную» учетную запись электронной почты, то это уже не модульный тест, а интеграционный тест ...

0 голосов
/ 08 октября 2009

Андрей прав насчет насмешки над почтовым API. Ваша проблема с этим, находящимся в C, может быть решена одним из двух способов.

  • предоставляет простую оболочку C ++, которая может быть подделана.
  • Используйте компоновщик для предоставления вашей тестовой / фиктивной версии C api, вы должны использовать те же заголовочные файлы, что и в библиотеке, но ваши юнит-тесты связаны с вашими фиктивными функциями C вместо библиотеки.

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

0 голосов
/ 08 октября 2009

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

...