[Опрос] Насколько глубо на Ваш взгляд и опыт стоит проектировать тестовый фреймворк?

база знаний
, , , , , , ,
#1

Дисклеймер: хоть варианты опроса и в полушуточной форме, но за ними лежит серьезный вопрос: насколько глубо стоит проектировать тестовый фреймворк? Поделитесь историями успеха

  • Все эти PageObject и ScreenPlay шаблоны были актуальны в эпоху динозавров. Сейчас предостаточно тулзов с рекордерами: пишем быстрые тесты, как есть, без даже минимального проектирования, а те, что ломаются, просто заново перезаписываем. Пока четвертые ↓↓↓ пишут свои абстрации, мы уже всё сделали и пьем пиво. С - скорость!
  • Пишем минимальные PageObject, чтобы осечь адское дублирование кода и ввести минимальную инкапсуляцию для читаемости, не более. Всё, что есть на странице: поля, кнопки, диалоги, зайцы, люди - вмешиваем в один класс. Любим мы, знаете, салаты из всего, что есть в холодильнике.
  • Пишем PageObject, как завещал дядюшка Боб: свой PageObject под каждый отдельный блок/диалог на странице. Но не упарываемся: если есть повторяющиеся блоки на разных страницах (фильтры, поиск, …), то лучше их описать отдельно описать на каждой странице, чем париться с иерархией классов, наследованием, композицией, … . Это как или кушать в ресторане всякий раз свежеприготовленное только для тебя, или в столовке когда-то приготовленное для народных масс, уже остывшее или подогретое в микроволновке - ну не вкусно же!
  • Тесты должны быть надежными и простыми в поддержке. А секрет успеха здесь прост и изучен - следуем принципам программирования, вводим абстракции, пишем по шаблонам, а сверху обсыпаем интерфейсами. Менее связанный код - быстрее и легче починка. Да, разобраться в этом новичку будет сложно, но всё равно легче, чем в адском спагетти у этих первых ↑↑↑.

0 участников

1 симпатия
Серия at.info опросов по автоматизации тестирования ПО
#2

Я бы рассказал не истоию успеха - а историю в процессе успех(надеюсь)
В общем надо было тесты фронта - которые могли бы проверять верстку в разных браузерах и разрешениях.
Решили упороться в скриншоты и сравнивать с шаблонами.
Ну и поначалу выбрали python так как новичкам, коих было 3 человека, оно понятнее.
Сделали стандартный pytest фреймворк по шаблону с пейджами и простой реализацией.
Скрины сравнивали через PIL библиотеку - срали шаблонами прям в репозиторий - и вот такой решение работало - все было очень просто но при этом выглядело страшно(и утилиты сравнения скринов и пейджи с дублированием и елочками ифов)
Ну и по отчетам прикрутили аллюр к этому всему в артефакты джобы по 100 мегабайт за прогон)

Так вот ситуация с фреймворком сейчас:
Сделали библиотеку ядро с разными обертками, настроили импорты убрали дублирование
Пейджи остались но они стали очень короткие, ифы и монстро методы убрали в пользу словарей и датапровайдеров. Сделали больше мелких шагов - читабельные тесты
Скрины стали брать и хранить в s3 - доставая на лету во время прогона, методы сравнения закинули в библиотеку. Запилили аллюр сервис и на него после прогонов отправляются allure-results, агрегируются там и хранятся.
Сделали интеграцию с тестрейлом с созданием тест ранов и подсчетом покрытия.
Ну и плюс много улучшений в сторону универсализации
Распространили решение уже на 5 сайтов.

Да есть проблемы - есть куда стремиться
Но в целом надо начинать с простого на мой взгляд, особенно если не обладаешь глубокой компетенцией и опытом.
У нас на момент создания фреймворка только у 1го сотрудника был опыт работы с питоно-фреймворками и то больше после самообучения + 1 коммерческий проект с апи тестами

Сейчас 4 сотрудника работает над автотестами - в целом есть проблемы с пониманием, но поддержка/разработка идет, главное что есть к кому обратиться за советами и помощью

Если говорить про временной промежуток - то это продвижение/успехи за год.

2 симпатии
#3

В том и вопрос: можно ли сегодня команде опытных автоматизаторов при построении нового фреймворка стремиться к упрощению тестов, игнорируя принципы и шаблоны проектирования? Сегодня фреймворки (вроде cypress и playwright) будто-то бы более высокоуровневые и менее требовательные к написанию чистого кода, чем selenium лет 10 назад. Какие тенденции в мире моды?

#4

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

#5

Вопрос как я понимаю - исключительно про Front-End UI визуальные тесты? :rofl::man_shrugging: PlayWright кстате отлично с PageObject Model логикой работает.
Вообще если говорить именно про ЮИ тесты - то эта срань конечно постоянно будет ломаться :smiling_face_with_tear: они исторически самые не стабильные тесты.
Я бы всё же советовал разделять и властвовать…
Не каждый функционал должен тестироваться в ЮИ. Для тестирования интеграции с сервером не нужен весь функционал. Для визуалых тестов пока ничего лучше сравнения скриншотов не придумали.
Cypress - пока еще не production ready tool. Уж слишком много ему для этого не хватало еще буквально год назад…
Ну и принципы программирования это же тоже та еще тема :rofl: сколько программистов, столько разных мнений. И про SOLID и композиции и интерфейсы…
Ну а по опыту - хороший фрэймворк: 1 - не ломается от каждого чиха. 2 - сразу даёт чёткое понятие что где и почему не работает :sweat_smile:
Всё остальное - попса…

#6

Можно и апи тесты строчить скриптовой портянкой, но да, в вопросе я подразумевал UI тесты, жаль не додумался в шапке указать

#7

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

#8

Если вы про генераторы тестов и кода для них - то они, на мой взгляд отлично могут использоваться под обучение автотестированию - но как инструмент?
Я бы не рисковал, там банально Arrange некорректно делается, ожидания элементов нет, нормальных ассертов и т.д.
Возможно мои знания устарели со временем Selenium IDE, но кодогенераторы на мой взгляд плохая идея)

#9

Всем спасибо за участие! Чаши весов с невероятным перевесом склонились в сторону “проектируй глуже - лучше будет”, вопрос только в том, насколько далеко идти в проектировании. Интересный холивар мог бы получиться между сторонниками 3 и 4 вариантов