Единичное тестирование содержимого электронной почты

Question

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

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

Редактировать: Чтобы уточнить, у нас уже есть отдельные тесты модуляции/интеграции для фактической отправки электронных писем, этот вопрос относится только к проверке содержимого электронной почты. В настоящее время мы тестируем только динамический контент, текст шаблона не находится в стороне от тестирования кликов.

Answer 1

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

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

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

// using C# syntax returning strings for the example -- you could just as easily return 
// System.Net.Mail.MailMessage or javax.mail.Message instead 
string BuildPasswordChangeTemplate(string username, string newPassword, string email); 
string BuildErrorTeplate(string methodName, string serviceName, Exception e); 

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

Answer 2

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

Answer 3

Мое основное правило: если оно влияет на работу приложения, проверьте его. (Да, это довольно свободно определенное правило.)

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

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

Answer 4

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

Answer 5

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

Если содержимое электронной почты является частью вашего кода , у вас должен быть какой-то тест вокруг него. Но, возможно, вам нужно больше проверить здравомыслие, чем проверить, что содержимое электронной почты точно соответствует «Поздравляю {NAME}, вы только что выиграли нигерийскую лотерею ...». Возможно, просто проверьте, что контент превышает порог определенного размера и что он содержит имя получателя (или какой-либо другой динамический контент), где-то в теле?

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

Answer 6

Единичные тесты для обеспечения работы всех ваших кодов слияния, если это конечный набор, или механизм слияния работает, если он является динамическим. Как и тест, который текст шаблона делает его объединенным документом, имеет смысл.

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