Вопрос по – Тестирование: как проверить, что представление содержит нужные данные

4

Скажите, что шеф-повар может делать рецепты, а су-шеф-повар может создавать рецепты, которые должны быть утверждены шеф-поваром.

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

Я могу придумать два способа сделать это:

Проверьте, что представление содержит определенные слова, такие как «Ваши рецепты» и «Рецепты, ожидающие вашего одобрения» Добавьте ненужные атрибуты к используемым html-элементам, чтобы можно было проверять наличие элементов с помощью «id = recipe_1» или «data-for-the-sake-of-testing = 1»

Мне очень не нравятся оба этих подхода.

Почему подход № 1 отстой Невероятно хрупкие тесты. Каждый раз, когда вы хотите внести небольшие изменения в копию, тесты будут прерваны. I18n? Как это будет работать с таким подходом?

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

Почему подход № 2 отстой

Как досадно иметь лишнюю разметку только ради тестирования! У пользователя не должно быть увеличенного размера загрузки для тестов.

Какой хороший подход к этому? Мне интересно услышать любые альтернативы, на любом языке, на котором вы думаете. Я в основном думаю на Ruby, Test :: Unit, Minitest, RSpec и Cucumber (хотя мои навыки работы с Cuke устарели), но если другие языки / рамки если бы это выяснилось, я бы тоже хотел посмотреть, что они делают.

Если приложение может декодировать ссылку "/ recipes / 1", это очевидно можно сделать =>, чтобы вы могли написать тест для этого. и строки локализации можно отследить до исходных идентификаторов, если вам нужно ... но я не написал книгу о тестировании, поэтому я не знаю, каков "правильный" способ сделать это;) Aprillion
разве это не ссылки? напримерhref=ddd?recipeid=1234? и вы можете проверить наличие всех ссылок, которые должны присутствовать (и никаких других ссылок нет), поэтому вам нужно иметь независимые списки рецептов (например, из предыдущих тестов или запроса к базе данных) .. Aprillion
В этом примере они, вероятно, будут ссылками. Но не обязательно. И URL-адреса могут измениться и, следовательно, также являются несколько ломкими. (i18n может изменить URL-адрес, как и реструктурировать его с "/ recipes? id = 1" на "/ recipes / 1".) Однако меня больше интересует общий случай необязательного текста ссылки. Как это проверить? chadoh

Ваш Ответ

4   ответа
4

Фразы описывайте как можно более на человеческом уровне, на уровне возможностей (высокий уровень), где это возможно, и используйте конкретные примеры. Например, если я использую огурец, я мог бы сказать:

Дай су шеф-повар создал рецепт для лягушачьего пирога
Когда шеф-повар ищет рецепты для одобрения
Тогда рецепт лягушачьего пирога должен быть в списке.

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

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

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

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

4

Избегайте тестирования бизнес-логики через пользовательский интерфейс. Напишите объект «service» или «use case controller», который возвращает простые структуры данных. Другими словами, вы создаете API для своей системы. Ваш юнит-тест получает доступ к системе через API. Ваш пользовательский интерфейс обращается к системе через тот же API, но тогда в представлении почти не должно быть логики. Видетьhttp: //www.confreaks.com/videos/759-rubymidwest2011-keynote-architecture-the-lost-year илиhttp: //www.cleancoders.com/codecast/clean-code-episode-7/sho.

Использовать " page object "pattern. Напишите объект, который читает в HTML-коде, который генерирует ваше приложение, анализирует его и делает интересные данные доступными через геттертес код понятен. Ваше возражение может заключаться в том, что у вас все еще есть проблема №2. На самом деле я не думаю, что это действительно проблема. Если вы используете структурную разметку HTML, будет достаточно легко извлечь нужную информацию. Будет намного проще, если вы прикрепите идентификатор к ключевому элементу страницы; в вашем примере у меня был бы div с id = "my-recipes" и еще один div с id = "to-Approved". Этого должно быть достаточно; все остальное должно быть легко найти с помощью селекторов xpath или css. Почему вы находите это нежелательным? Эти идентификаторы, вероятно, будут полезны для других целей, таких как присоединение поведения с помощью ненавязчивого JavaScript или присоединение стилей с помощью таблицы стилей CSS.

Отличный ответ и ссылки! Я должен занять некоторое время, чтобы обработать это. Но чтобы ответить на ваш вопрос: добавление лишних идентификаторов только для тестов кажется, что я сейчас пишу код для меня, а не для моего клиента. Мой клиент теперь имеет увеличенный размер файла без какой-либо выгоды для него. Ифф JS или CSS нужно подключить к элементу, а затем (возможно, незначительный, я понимаю) увеличение размера файла принесет пользу клиенту. chadoh
Спасибо тебе, Чадо. Я понимаю вашу озабоченность, но я все еще чувствую, что наличие хорошо протестированного продукта Делает принеси пользу своему клиенту: -) xpmatteo
1

возможно, используя краткие комментарии (никаких проблем с i18n и не видимых для конечного пользователя):

<!-- APPROVAL -->

The документация о простейшем имеет хороший взгляд на это:

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

Если небольшое количество лишней разметки делает ваш продукт более тестируемым и надежным, чем просто жить с ним!

# 2 явно лучше, чем # 1, но все равно заставляет меня вздыхать. Интересно, что ЭЭ приходится оставлять в излишних булавках, но в цифровом мире мы можем найти более элегантное решение. chadoh
омментарии @HTML очень сложно использовать в модульном тесте. Гораздо лучше использовать атрибуты id или class, чтобы их можно было использовать в запросах xpath. xpmatteo
assertPattern ('# RECIPES_FOR_APPROVAL #', $ output) не кажется таким уж сложным. Кажется более понятным сделать ярлыки тестов явными, а не использовать идентификаторы и атрибуты класса, которые могут / должны меняться в соответствии с вашими бизнес-требованиями. Ken
1

анную разметку, поскольку эти тесты кажутся очень хрупкими.

Instead, я сосредотачиваюсь на стороне «поставщика данных», в случае MVC веб-фреймворк - Controller. Как только контроллер проходит модульные тесты, которые проверяют, какой тип контроллера данных готовится, вы в значительной степени в безопасности. Представление, которое вы создаете, легко проверить, просто запустив приложение и увидев, что оно выглядит нормально.

Nethertheless, есть несколько подходов к тестированию представлений. Первый основан на "сквозном" моделировании тестирования с Selenium Driver. Он запускает браузеры и инициализирует запросы к вашему приложению. Тесты проверяют вывод HTML. Тестирует вход в «известную» редакцию, это означает, что тесты знают, например, что текущая локализация - E

Вы должны в основном комбинировать подходы, где это работает, использовать значения разметки HTML («Recipies»), в противном случае использовать идентификаторы или классы HTML-элементов. Я бы не стал добавлять дополнительную разметку для тестирования.

Другой подход, который вы можете попробовать, это одобрительное тестирование. Я считаю, что для этого есть драйвер Ruby -http: //approvaltests.sourceforge.net. С одобрениями вы отображаете представление и сохраняете HTML как золотой мастер. Тест не пройден в случае изменения View. Это гораздо проще реализовать, чем тесты Selenium.

Похожие вопросы