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

Question

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

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

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

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

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

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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

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