Звіт із Selenium Camp 2017, про архітектуру тестів

Був оце на Selenium Camp 2017
Все дуже сподобалось! І місце, і доповіді, і відвідувачі. Особливо на віскі-паті :-)
Після кожної доповіді я ставив питання, а на майстер-сесії питань-відповідей навіть трохи попав у кадр і змусив усіх відповідати, як мати справу із великими тестовими базами, отримавши кілька робочих ідей!
І навіть той раз, коли одна з презентацій перетнула нижню межу цікавості, час не був втрачений, бо в коридорі нас спіймали журналісти і взяли інтерв’ю. 

Ще раз дякую команді організаторів!

Свій звіт я хочу зробити досить нестандартно. Відео всіх доповідей ви самі можете подивитися на офіційному каналі, тому немає сенсу їх переказувати. Я ж просто поділюся тим, що було нового впродовж двох днів конференції саме для мене на кожну з тем, не прив’язуючись до якоїсь конкретної презентації.
 

Усі мої нотатки можна розділити на 3 групи:

• Збір та аналіз статистики результатів тестування
• Архітектура автоматизації (поради щодо PageObject та інших паттернів)
• Безперервне впровадження (Continuous Deployment): Github Flow, середовища розробки, постійне тестування на робочому середовищі

Хочу почати з архітектури, бо про це в мене найбільше нотаток.

Що таке "добрі локатори" на web-сторінках

Писання автоматизованих тестів для web GUI складається, великою мірою, не тільки з логіки перевірок та вигадування моделі тестових даних, як під час тестування API, а ще й із прив’язування логіки тесту до правильних елементів на сторінці, тобто - побудови локаторів.
Окрім усім очевидних методів пошуку елемента за id чи ім’ям класу (class name), іноді у нагоді стають css-selector'и та xpath'и, що дозволяють вкласти певну логіку у спосіб пошуку, та значно полегшити код самої перевірки, звівши її до простої присутності елемента за зазначеним локатором. Але який локатор вважати добрим?