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

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

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

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

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

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

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

# PageObject та інші паттерни

Хоч я й не пишу на Java, але останнім часом горщик із паттерновою кашею став варити особливо сильно, і шаблони проектування вже мусить знати навіть той, хто ніколи їх не використовував, пишучи наприклад на Пайтоні. Мабуть це пов’язано із тим, що Джава набридла самим джавістам, і вони шукають собі нових способів сомореалізації, вивчаючи інші мови, і приміряючи туди свої Java-навички. І це непогано, бо змушує таких ледацюг як я вчити значення нових слів та конструкцій. Спонукає до міжгалузевого діалогу, так би мовити :-)
Для тих, хто хоче взнати, які із паттернів можна застосовувати в автоматизації, можете подивитись усю доповідь шановного Мікалая Аліменко́ва із цього приводу.
Мені ж припав до душі останній пункт - Steps. Саме цього мені не вистачало, щоб зрозуміти, як же легко перетворити мої пейджобжектові тести на те, що в народі називають BDD; хотів і ніяк не міг осягнути Gherkin Language. Я чомусь не бачив цієї простої концепції:
Інкапсуляція тестових кроків у методи і присвоєння їм довгих людино-читних назв.
Крім того, розділивши сторінки і самі тести можна гнучкіше керувати реалізацією кожної дії тесту, не змінюючи сам тест, його мету і сенс.
Це відкриває можливість до реалізації однієї з порад із книжки "The A Word": реалізація випадкового вибору з кількох способів зробити ту ж саму дію.

# Локатори

Крім тестів кожен доповідач згадував якість та надійність використаних локаторів. Я теж колись писав про це. Ось кілька порад, що варті уваги:
- Найкращими локаторами є унікальні, зрозумілі, слабко змінювані айдішники елементів. Із цим важко сперечатись, але де їх взяти? - спитаєте ви? Це очевидно: просити девелоперів! Адже testability - це один з показників якості продукту загалом. Тому добрі локатори залежать від спілкування між тестувальниками та програмістами. Доречі, непогана статична метрика коду могла б вийти: "Оцінка здоров’я стосунків у команді по якості локаторів в автотестах". :-)
- LinkText - поганий локатор, бо із ним вам прийдеться переписувати ваш PageObject під кожну мову інтерфейсу, що є на вашому сайті.
- Я не знав, що у JS консолі бравзера можна дебажити свої локатори отак:
$$('#hplogo') - для CSS селекторів
$x('//*[@id="hplogo"]') - для XPATH
... і ще кілька цікавих способів тут: https://developer.mozilla.org/en-US/docs/Tools/Web_Console/Helpers
Я для цього завжди відкривав ще один бравзер через WebDriver у Python консолі. А так стільки рухів економиться!

# Оцінка якості коду тестів

Що таке погана автоматизація?
- Її треба постійно підтримувати
- Вона повільна
- Дає ненадійний результат: хибно позитивний (падає без причини - пів біди) чи хибно негативний (не показує проблем - можлива катастрофа!)
Чи можна оцінити погані якості коду тестів без його запуску?
Маркус Маррелл каже - можна!
Він перераховує ознаки поганої автоматизації (виклик Selenium методів у тесті, умови у тесті і т.ін.), і за кожну знімає бали. А скільки ви собі зняли би балів? :-)

# Розділення тестів за тривалістю

Усі, мабуть, знають, що у Ґуґлі відбувається із вихідним кодом. А Еран Нелінґер із ізраїльского офісу розповів, як вони це все тестують. Що тести діляться не на рівні, а просто за тривалістю виконання: маленькі, середні, великі.
Власне, все було давно написано у цьому блозі: https://testing.googleblog.com/2010/12
/test-sizes.html
З інших презентацій сюди можна додати кілька порад для прискорення тестів:
- Первіряти в різних тестах, що пишеться в базу, і що читається з бази
- Готувати дані заздалегідь
- Використовувати той самий бравзер/вебдрайвер для кількох тестів підряд, просто чистячи куки
- Передавати в бравзер готові куки для певного користувача, не отримуюючи їх від сервера під час тесту

Мабуть, у кожній презентації на цій конфі була піраміда, але оця мені сподобалася найбільше:

 

Розмір(тривалість) тестів та їхня кількість

У наступних частинах розповім про аналіз результатів та все інше. Далі буде...