Добрый день!
Есть у меня такой вопрос. Возник не на пустом месте, а в рамках обсуждения с коллегой #architecture тестового #framework . И его подход мне показался немного странным. Хотя с его слов, подход этот уже успешно применялся в его практике на других проектах и там это было стандартной практикой. И наоборот там его учили делать именно так. Вот эту тему пролистал: Архитектура и инфраструктура автоматизации тестирования ПО, посмотрел картинки, большинство из них не понял. 
Так вот в чем собственно вопрос: тест должен содержать только лишь проверки, по сути ассерты, или же он должен содержать в себе логику и действия (шаги выполнения)?
Лично я придерживаюсь того мнения, что тест без описания того какие шаги в нем выполнялись и какие были предусловия выполнения - это и не тест вовсе и беру за основу тот же #bdd подход, где сценарии описывают и поведение и ожидаемый результат. С его же слов, нужно всю эту логику выносить за тест и делать предварительно, а в тесте уже проверять сами результаты. Но мне кажется, что это делает #framework тяжеловесным, плохо расширяемым и запутанным. Намного проще когда класс теста один и внутри него есть все, что нужно чтобы понять как и почему он работает. Конечно, при этом общие методы, данные и т.п. штуки могут и должны быть вынесены наружу в отдельные вспомогательные классы, чтобы не создавать копи-пасты и максимально переиспользовать внутри тестов уже готовые решения.
Кажется, тест это есть совокупность шагов. Причем крайне желательно валидировать результат выполнения каждого шага, чтобы точно указать на проблемное место в тесте. По поводу того, чтобы всю логику сделать в precondition’e - это больше про юнит-тесты, где концепция один тест - один ассерт себя очень оправдывает. Но в сложных функциональных тестах это уже не прокатит, там лучше делать шаги и придерживаться BDD.
1 лайк
Да, мне тоже так показалось, что в его прошлом опыте использовался подход из unit-тестов.
Сейчас же у нас текущие проекты связанны с функциональным системным и интеграционным тестированием, и поэтому мне данный подход и показался крайне сомнительным. Но я пока не лезу в чужой “огород” в смысле код, хотя немножко и боязно, если все это разрастется в неуправляемую махину со сложностью которой будет невозможно бороться (проекты у нас сейчас различные).
Хотелось бы услышать мнения других людей, кто и как организует тесты у себя. Какие подходы применяет и почему.
Что такое шаги в тесте? это то же управление функциями приложения как и в самом приложении, только через другие инструменты. Представьте, если бы разработчики помещали код логики в обработчики нажатия и взаимодействия с кнопками, дроп-даунами и другими веб элементами. В тесте должны готовиться данные, специфичные для данного теста, если такое имеет место быть, и интерпретация полученных данных: где-то сообщение об ошибке означает ошибку в коде, а в каком-то тесте оно ожидаемо. Вынос логики за пределы теста явно разделяет зоны отвественности: тест не должен управлять бизнес логикой: тест должен вызывать элементы бизнес-логики. Например, код ниже имеет не удачную реализацию, тк смешивает 2 зоны отвественности: поиск элемента и проверка результата (причем еще идет и смешивание уровней: более низкого(поиск элемента через вебдрайвер, и более высокого: проверка текста):
assertTrue(Webdriver.find_element(By.text("Home page").get_text().equals("Home page"))
Хорошая архитектура - всегда модульная (имеются ввиду не кратко-срочные проекты). Каждый модуль должен иметь свою зону ответственности. Чем более четко и удачно вы выделите эти зоны, тем более удачно и предсказуемо будет идти ваш проект.
2 лайка
Если честно, то пример проверки, где ищется элемент по тексту “Home page” и далее проверяется, что текст у этого элемента именно “Home page”, мягко говоря высосан из пальца и страдает даже не от архитектурных просчетов, а скорее от наличия нормальной логики. Возможно, кто-то так и пишет, но тут понятно просто человек не понимает даже, что собственно он делает и зачем.
Вот если бы вместо этого искался элемент по XPath или по ID или еще как-то и затем проверялся его текст на соответствие какой-то константе, то тут бы хотя бы был намек на то, что тест содержит в себе логическую часть.
Михаил, смысл примера не показать, насколько логична или не логична проверка, а показать ошибку архитектуры в назначении нескольких зон отвественности для класса/метода/теста
testomat.io управление авто тестами