Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 6
Мы не тестировали АЕМ, а разобрались с его API для более простого тестирования нашего приложения построенного на базе АЕМ. Видимо стоило написать Test Automation of AEM Based Application.
Фильтрация страниц, порядок их отображения и сортировка, по-сути все.
У меня встречный вопрос, был ли у вас опыт работы с АЕМом?
У меня встречный вопрос, был ли у вас опыт работы с АЕМом?
Тогда отвечу по-порядку.
Что я увидел в АЕМе — он предоставляет набор след. инструментов:
— компоненты из которых можно собрать страницу.
— возможность кастомизировать компоненты (стили и логику)
— возможность создавать свои компоненты, со своим стилями и логикой (например компоненту отображения продуктов, если все правильно настроено, залогиненого юзера, по нажатию на один из продуктов, переведет на подтверждение оплаты продукта) + если девы реализовали такую возможность, можно сконфигурировать выбранный компонент, например для какого-то продукта, и если у юзера недостаточный баланс, вместо уведомлении о недостаточном балансе, мы предложим ему оформить рассрочку (п.с. пример не из реальной жизни).
— еще кучу всего, с чем я не столкнулся.
Суть в том, что мы, как команда разработки, не создаем сами страницы. Мы реализуем админку, с помощью которой ЕДИТОР (сотрудник нашей компании) будет создавать конечные страницы. Таким образом мы несем ответственность не только за финальную страницу видимую конечному пользователю, но и за админку. Если говорить о маленьких компаниях, они врядли выберут АЕМ. А вот в больших, вы можете даже никогда не узнать, как именно ЕДИТОР соберет страницу.
Это приводит нас к тому, что хорошо бы производить тестирование связи — админка (так называемый АЕМ-author) + финальная страница (АЕМ-publish). Ведь где гарантия, что компонента с продуктами нормально отображается и работает со всеми типами продуктов.
Я много гуглил, как другие компании тестируют свои приложения построенные на базе АЕМа. К сожалению информации практически нет.
Документация АЕМа рекомендует использовать Selenium без какого-либо детального описания. Несколько решений, которые я нашел, подразумевали написание скриптов (использующих тот же Selenium), которые ходили бы в админку, меняли там, что-то, а потом проверяли изменения на конечной странице (АЕМ-publish).
Если вы понимаете в автоматизации — это не самый оптимальный подход, да и сильно бьет по времени прогона тестов. Так что мы попробовали подход, который я описал.
В моем случае, как я писал, мы реализовывали темплейты (шаблоны) страниц (точнее статей) и определенную логику автоматического отображения этих страниц на других страницах. При чем, в зависимости от разных критериев, эти статьи автоматически отображались или скрывались. Или же, в зависимости от критериев, статья могла располагаться в разных местах на страницах. Это все могли кастомизировать под свои нужды ЕДИТОРы в админке.
Учитывая все выше сказанное, у меня было несколько вариантов тестирования:
— создать кучу разных вариаций сетапа статей и страниц на которых они будут отображены. По грубым подсчетам это было бы около 50 страниц, для более менее сносного покрытия. — Минус в таком подходе — статические страницы не будут обладать атрибутами добавленными в последних итерациях. И если они важны, придется пересоздавать страницы с нуля, а это время затратно
— автоматизировать создание нужных мне статей — тут как я уже писал было 2 варианта: а) через юай, б) любым другим способом
Собственно в статье, я описал способ который мы нашли и реализовали. И честно говоря, если бы я встретил подобную информацию раньше — она бы очень упростила мне жизнь и сэкономила кучу часов.
Порядок отображения и сортировка суть одно и тоже так-то.На самом деле сортировка = порядок отображение, правда порядок != сортировка.
Похоже на то что AEM это CMS типа вордпресса и вы кастомизировали какой-то из их плагинов для какого-то корпоративного сайта.И да, и нет. К сожалению я не работал с Wordpress, а то что я слышал — он намного проще АЕМа. Что такое АЕМ лучше почитать отдельно т.к. я не эксперт в нем. + посмотреть примеры сайтов построенный на основе АЕМа (вот несколько примеров, если верить интернету — fedex.com, samsung.com, support.apple.com, credit-agricole.fr)
Что я увидел в АЕМе — он предоставляет набор след. инструментов:
— компоненты из которых можно собрать страницу.
— возможность кастомизировать компоненты (стили и логику)
— возможность создавать свои компоненты, со своим стилями и логикой (например компоненту отображения продуктов, если все правильно настроено, залогиненого юзера, по нажатию на один из продуктов, переведет на подтверждение оплаты продукта) + если девы реализовали такую возможность, можно сконфигурировать выбранный компонент, например для какого-то продукта, и если у юзера недостаточный баланс, вместо уведомлении о недостаточном балансе, мы предложим ему оформить рассрочку (п.с. пример не из реальной жизни).
— еще кучу всего, с чем я не столкнулся.
Суть в том, что мы, как команда разработки, не создаем сами страницы. Мы реализуем админку, с помощью которой ЕДИТОР (сотрудник нашей компании) будет создавать конечные страницы. Таким образом мы несем ответственность не только за финальную страницу видимую конечному пользователю, но и за админку. Если говорить о маленьких компаниях, они врядли выберут АЕМ. А вот в больших, вы можете даже никогда не узнать, как именно ЕДИТОР соберет страницу.
Это приводит нас к тому, что хорошо бы производить тестирование связи — админка (так называемый АЕМ-author) + финальная страница (АЕМ-publish). Ведь где гарантия, что компонента с продуктами нормально отображается и работает со всеми типами продуктов.
Я много гуглил, как другие компании тестируют свои приложения построенные на базе АЕМа. К сожалению информации практически нет.
Документация АЕМа рекомендует использовать Selenium без какого-либо детального описания. Несколько решений, которые я нашел, подразумевали написание скриптов (использующих тот же Selenium), которые ходили бы в админку, меняли там, что-то, а потом проверяли изменения на конечной странице (АЕМ-publish).
Если вы понимаете в автоматизации — это не самый оптимальный подход, да и сильно бьет по времени прогона тестов. Так что мы попробовали подход, который я описал.
Статься если я правильно понял про подготовку тестовых данных. Если так, то реверс-инжиниринг здесь как из пушки по воробьям. То есть это конечно мощно и громко и пару воробьев вы зацепите. Вот только возможно есть более дешевые решения.На счет «из пушки по воробьям», если говорить о обычных сайтах визитках — согласен на все 100%.
В моем случае, как я писал, мы реализовывали темплейты (шаблоны) страниц (точнее статей) и определенную логику автоматического отображения этих страниц на других страницах. При чем, в зависимости от разных критериев, эти статьи автоматически отображались или скрывались. Или же, в зависимости от критериев, статья могла располагаться в разных местах на страницах. Это все могли кастомизировать под свои нужды ЕДИТОРы в админке.
Учитывая все выше сказанное, у меня было несколько вариантов тестирования:
— создать кучу разных вариаций сетапа статей и страниц на которых они будут отображены. По грубым подсчетам это было бы около 50 страниц, для более менее сносного покрытия. — Минус в таком подходе — статические страницы не будут обладать атрибутами добавленными в последних итерациях. И если они важны, придется пересоздавать страницы с нуля, а это время затратно
— автоматизировать создание нужных мне статей — тут как я уже писал было 2 варианта: а) через юай, б) любым другим способом
Собственно в статье, я описал способ который мы нашли и реализовали. И честно говоря, если бы я встретил подобную информацию раньше — она бы очень упростила мне жизнь и сэкономила кучу часов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
AEM Test Automation — Create Pages via HTTP Requests