Есть ли ощутимое значение в модуле тестирования собственных htmlhelpers? Многие из этих вещей просто выплевывают кучу html-разметки - мало логики нет. Итак, вы просто сравниваете одну большую строку html с другой? Я имею в виду, что некоторые из этих вещей требуют, чтобы вы просмотрели сгенерированную разметку в браузере, чтобы убедиться, что это нужный вам результат.Зачем мне проверять мои HTML-подсказки?
Кажется немного бессмысленным.
Да.
Хотя теперь может быть мало логики, это не значит, что в пути не будет больше логики. Когда эта логика добавлена, вы хотите быть уверены, что она не нарушит существующие функции.
Это одна из причин, по которой написаны Unit Tests.
Если вы следуете за Test Driven Development, сначала пишите тест, а затем записываете код для тестирования.
Это еще одна причина.
Вы также хотите убедиться, что вы идентифицируете и проверяете любые возможные кромки с вашим помощником (например, неэкранированные HTML-литералы, незашифрованные специальные символы и т. Д.).
Почему вы ставите логику в html-помощнике? Разве это не должно быть в вашей модели? Кроме того, если вы используете модель для генерации html (например, HtmlTags или даже TagBuilder), вам даже не нужно будет беспокоиться о том, что генерируется. – Ryan
@ Ryan - Модель - это данные yor. Там вообще не должно быть никакой логики. Html Помощники там строго, чтобы помочь View визуализировать модель должным образом. В зависимости от модели может понадобиться простая логика для правильного отображения вещей в браузере. Другие помощники сложнее ... например, Html.TextBoxFor(). –
«Модель - это ваши данные ... там вообще не должно быть никакой логики». Я действительно не уверен, что сказать. Либо у нас есть разные идеи о том, что такое модель, либо вы работаете напрямую с объектами СУБД. Я лично предпочитаю богатую модель поведения. Что касается html-помощников, я думаю, что мой самый сложный из них состоит из 3 строк, и это просто вызов шаблонной структуры, которую я заимствовал у FubuMVC. – Ryan
Я думаю, это зависит от того, сколько человек будет использовать/модифицировать его. Обычно я создаю единичный тест для html-помощника, если я знаю, что многие люди могут это понять или логика сложна. Если я буду использовать его только, я не собираюсь тратить свое время (или деньги моего работодателя).
Я могу понять, что вы не хотите писать тесты, хотя ... может быть довольно неприятно писать несколько строк кода генерации HTML-кода, для которого требуется 5X, чтобы проверить.
Он принимает простой ввод и предоставляет простой выход. Это хорошо для TDD, так как время, которое вы собираетесь потратить на build-> start site-> исправить эту глупую проблему-> начать снова, -> oops, пропустил эту другую крошечную вещь -> начать ... мы закончили , счастливый :). Dev 2 приходит и делает небольшие изменения, чтобы «исправить» его для чего-то, что тогда не работало, тот же цикл продолжается, и dev 2 не заметил, когда он нарушил ваши другие сценарии.
Вместо этого вы v. Быстро выполните простой простой текст, y, что простой вывод дал вам тот простой результат, который вы ожидали со всеми закрывающими тегами и кавычками, которые вы ожидали.
Написав HTML Helpers для меню sitemap, например, или кнопки для рамки мастера, я могу заверить вас, что некоторые помощники имеют много логики, которые требуют проверки, чтобы быть надежными, особенно если они предназначены для использования другими.
Так что это зависит от того, что вы с ними делаете. И только вы знаете ответ на этот вопрос.
Общий ответ: Html Helpers может быть сколь угодно сложным (или простым), в зависимости от того, что вы делаете. Поэтому без проблем, как и с чем-либо еще, нужно проверить, когда вам нужно.
Да, есть ценность. Сколько нужно определить. ;-)
Возможно, вы начнете с базовых тестов «возвращает все», и не особо заботятся о том, ЧТО. В основном просто быстрые тесты на здравомыслие, в случае чего-то фундаментального разрыва. Затем, когда возникают проблемы, добавьте больше деталей.
Также рассмотрите вопрос о том, чтобы ваши тесты анализировали HTML в DOM, которые намного легче тестировать, чем строки, особенно если вы ищете только определенный бит.
Или ... если у вас есть автоматические тесты против самого webapp, убедитесь, что есть тесты, которые специально предназначены для вывода ваших помощников.
Да, он должен быть протестирован. Основное эмпирическое правило, если оно не стоит тестировать, не стоит писать.
Однако, когда вы пишете свои тесты, вам нужно быть осторожным. Существует опасность того, что они могут быть очень «хрупкими».
Если вы пишете свои тесты, чтобы получить конкретную строку, и у вас есть помощники, которые вызывают другие помощники. Изменение одного из основных помощников может привести к неудаче многих тестов.
Так что, может быть, лучше проверить, чтобы вы вернули ненулевое значение или что конкретный текст содержится где-то в возвращаемом значении. Вместо того, чтобы тестировать точную строку.
Ознакомьтесь с использованием HtmlTags, чтобы сгенерировать свою разметку. Он включен в FubuMVC, но вы можете создавать его отдельно. Вам не придется беспокоиться о закрытии тегов или неверных котировках. – Ryan