t.me/atinfo_chat Telegram группа по автоматизации тестирования

Оправдано ли использование PageObject паттерна


(Shaman) #1

В последнее время просматривал свои тесты и пришел к выводу что они немного неэстетичны. решил порефакторить. Полистал информацию по PageObject паттерну, с виду все понравилось. попробовал написать небольшой пробный каркас. Написал - понравился вид кода. теперь сижу и думаю, стоит ли строить новый фреймворк и переводить 2-3 десятка тестов под него, учитывая то что разработка фреймворка займет несколько недель.

 

из плюсов вижу: удобночитаемый и удобноподдерживаемый код, рефакторинг существующих тестов(немного набрался опыта и имею новое видение структуры).

из минусов: как по мне весьма длительная переработка тестов.

какие еще плюсы и минусы есть у данного паттерна?

 

З.Ы. может все таки стоит прислушатся к старому анекдоту:

Сидит программист глубоко в отладке.
Подходит сынишка:
- Папа, почему солнышко каждый день встает на востоке, а садится на западе?
- Ты это проверял?
- Проверял.
- Хорошо проверял?
- Хорошо.
- Работает?
- Работает.
- Каждый день работает?
- Да, каждый день.
- Тогда ради бога, сынок, ничего не трогай, ничего не меняй.


(Наталия Кудлай) #2

Плюсы в перспективе - если проект будет развиваться (2-3 десятка тестов это мало, если они написаны грамотно, т.е. небольшие, проверяют какую-то конкретную фичу и независимы между собой), стоит перейти на этот паттерн. Конечно речь идет о проектах, работающие с UI (к тестированию веб-сервисов или еще чего-то не связанного с условными страницами как сущностями такой подход неприменим).

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

Минусов сходу придумать не могу - надо смотреть на специфику проекта. Например, если он очень простой и развиваться вряд ли будет, то и усложнять не надо.


(KaNoN) #3

Переработка тестов необязательно должна быть всеобъемлющей. Вам ничего не мешает писать новые тесты с новыми структурами, при этом поддерживая работоспособность старых тестов. Как только какой-то старый тест дает сбой, вы можете его подкорректировать уже используя новые наработки. Таким образом вы более-менее эфективно можете распределять время. С одной стороны вы продолжаете развивать автоматизацию, покрывая все больший объем функционала. С другой стороны вы тратите время на актуализацию существующего кода тогда, когда в этом есть насущная необходимость (если ГУИ меняется, то вполне логично, что и тесты надо как-то адаптировать).


(Дмитрий Жарий) #4

 

Поддерживаю.  И хочу поделиться реальным кейсом.

В наследство, мне на проекте досталось около 300 тестов, которые были написаны в стиле Record&Play, хотя писались и копи-пастились руками. Самое ужасное в том, что эти тесты даже находили баги. На них было потрачено куча ресурсов и выбрасывать мне их запретили.

Так как над тестовым набором долгое время никто не работал, то вначале было около 80% фейлов.

За два месяца мы довели этот показатель до 20%.

В это же время, я писал свой фреймворк с PageObject, хорошей структурой и блекджеком и имплементировал новые тесты уже на нем.

Так как старые тесты выбрасывать было нельзя, для того чтобы объединить «старый» и «новый фреймворк», я создал в новом фремворке некоторое «гетто» для старых тестов.  Это была обычная папка с именем Legacy, которая никак не влияла на новый фреймворк с одной стороны, а с другой стороны имела возможность использовать все плюшки нового фреймворка.

И старые и новые тесты были написаны в одной среде. И это очень важно.

Тест раннер: MS Test

Веб драйвер: WatiN

Язык программирования: C#

Так что с интеграцией у меня проблем не было.

Вместе эти два фреймворка прожили около 2-х месяцев.  Я правил старые тесты м писал новые.

 

А потом случился апокалипсис.

Разработчики решили переписать UI приложения с ASP.NET на ASP.NET MVC

Все id элементов и структура страниц была изменена, и понятное дело, что и старый и новый фреймворк оказались в реанимации.

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

Новый фреймворк мне удалось полностью реанимировать за 4 дня и при этом я значительно порефакторил его код. 

 

В итоге:

1.  Старый и новый фреймворки можно интегрировать вместе, при условии что они использую одну среду разработки и прогона тестов.

2.  Новые тесты нужно продолжать писать на «новом» фреймворке.

3.   Со временем можно переписать тесты из старого фреймворка в новый. 

 

Времени на полное переписывание старого кода скорее всего не выделят

Возможно, и не стоит это делать сейчас. В «новом» коде тоже могут быть изъяны,  которые откроются со временем. Если вы перепишете все старые тесты сразу, то возможно, они уже будут  содержать ошибки.

К примеру,  в новом фремворке я использовал Specflow (это реализация Cucumber для .NET), и не смотря на все его плюшки, для меня составляло сложность правильно оформлять тесты. Я тратил на это очень много времени и уже ощущал некоторые ограничения фреймворка. Потом я перешел на BDDify, который снял самые важные для меня ограничения. Но, для миграции тестов мне понадобилось 2 дня.

На соседнем проекте использовался Fitnesse для .NET.  Там тоже столкнулись с ограничениями инструмента и решили перейти на Specflow, чему сейчас очень довольны.