«Для тих, хто хоче, але боїться автоматизації»#

Не знаю, як для кого звучить згадка про тестовий фреймворк, але для мене, перш ніж став «тісно» працювати над автоматизацією слова когось на конференції/у відео-уроці «Я написав свій тестовий фрейморк» викликали шанобливу повагу та «тремтіння у колінах». Що цілком легко зрозуміло було, оскільки знань з програмування та розуміння того, з чим доведеться працювати було замало і по суті фраза сприймалася як «я написав свій ще крутіший варіант Selenium».

Гугління і вікіпедіння не дуже допомагало, тому що скрізь також зустрічалися визначення типу «програмний продукт», «набір бібліотек» тощо. Асоціативний ряд відразу виводив до деяких .dll файлів, які виникають якимось складним і фантастичним чином.

Насправді все не так. Точніше, не так «складно та фантастично». У всіх (які мені зустрічалися) курси автоматизації тестування з використанням Selenium перші уроки починаються з навчання роботі з Selenium IDE. Можливо, зі зростанням популярності Selenium Builder курси починатимуть навчати працювати з ним – але це так, ліричний відступ. Так ось, перший скрипт з IDE є набором команд, які є реалізацією фреймворку Selenium/Webdriver. Якщо його зберегти, підпиляти – то, в принципі, можна з ним і надалі працювати. Але проблема полягає в тому, що доведеться далі в тестах використовувати одні й ті ж повторення команд, одні й ті самі переходи, одні й самі алгоритми, елементи на сторінці/у вікні тощо, і т.д. Це незручно, довго та нудно. Набагато швидше вирішити квадратне рівняння за формулою (згадуємо шкільний курс:)), ніж будувати на мілімітровці графіки щоразу.
Тобто. насправді, “тестовий фрейморк” – це “конструктор, зроблений з конструктора”.
Один простий приклад: натиснути кнопку «Зберегти».
Можна завжди у тестах писати так:

<pre data-wpae="lang:csharp;theme:github;" style="background-color: #ddd;">driver.FindElement(By.Id("ctl00_A_btnSave")).Click();

Але що робити, якщо таких записів «багато-багато», а треба щось змінити? Або змінилося (в самому Selenium) назва методу натискання на елемент (став не Click(), а ClickElement()), або змінився ID, або ще якесь або? Для цього локатор зберігається окремо (в описі сторінки для PageObject/елемента сторінки HtmlObject), метод описується окремо, а всередині знаходиться той самий

<pre data-wpae="lang:csharp;theme:github;" style="background-color: #ddd;">driver.FindElement(By.Id(locator)).Click();

І так, малими «цеглинами», вибудовується оперування сторінками/вікнами/діалогами, а потім з цих «найбільших цеглинок» збираються тести. Що буде найважливішими моментами при початку роботи над «своїм дітищем» (що дозволить потім вийти на сцену на конференції з тестування і гордо випнувши груди сказати «я написав свій тестовий фреймворк»:))?

  1. Розуміння плюсів/особливостей мови, якою писатиметься. Зі своїх граблів: перші спроби «автоматизувати» довелося викинути/переписувати через те, що тести об’єкто-орієнтованою мовою писалися «по-старому». І змусити працювати «того монстра Франкенштейна» вдалося, але через тоді «незрозумілі милиці».
  2. Знання патернів (шаблонів, прийомів) проектування для тестових фреймворків. В інтернатах інформації багато, можливо, трохи пізніше «напишу і своє велосипедне пояснення». Зараз просто напишу так: якщо не знаєш, що має вийти – то може взагалі щось нікому незрозуміле.
  3. Планування. Не можна автоматизувати відразу і все. Почніть із простих сценаріїв.

Кому як, а для мене добрим підходом здається наступний:
а) написати тест-кейси «на папірці»
б) перенести в тестовий проект у «командному» вигляді, тобто. не

<pre data-wpae="lang:csharp;theme:github;" style="background-color: #ddd;">driver.FindElement(By.Id(locator)).Click();

а

Site.OpenPage(page1);
Site.Page1.ButtonSavePresent();
Site.Page1.ButtonSaveClick();

який природно не проходитиме, оскільки всі (або частина) ці методи ще реалізовані.
в) реалізувати методи, виходячи з того, що OpenPage «глобальніший», а

<pre data-wpae="lang:csharp;theme:github;" style="background-color: #ddd;">Page1.ButtonSaveClick();

стосується лише Page1. І ось якраз цей самий момент реалізацій пункту і буде «тестовим фреймворком автоматизації».
г) підготувати “code convention”. Навіть якщо автоматизацією на проекті займатиметься одна людина – варто заздалегідь продумати певні правила, як саме писати як код тестів, так і код «конструктора». Бажано обговорити з програмістами, бо якщо знадобиться їхня порада, щоб не виявилося, що код «написаний на абсолютно різних діалектах однієї мови». (Елементарне: як ставити фігурні дужки? На цьому ж рядку відкривати – чи з наступного? Якщо можна «і так, і так».)

Природно, у фреймоврк варто заздалегідь закладати репортинг/логування результатів/звітність. Якщо це нове для вас – то не варто одразу чекати побудови гарних графіків. Відразу варто пам’ятати, що кількість тестів буде не 10 і тестових оточень буде більше ніж одна, а значить Grid і паралельне виконання тестів наближається. Звичайно не варто «відразу писати тести по всьому»: покрийте базову функціональність, основні сценарії, а потім приступайте до детальніших перевірок «всього». Природно, що тестових даних буде багато, а значить один і той же сценарій працюватиме на багатьох наборах даних (які читатимуться їх файли, бази даних, генеруватимуться «на льоту» залежно від контексту). Роботи багато, часу на реалізацію займе багато, особливо якщо з мовою програмування «на Ви» (про те, яку мову вибрати – теж треба подумати заздалегідь: якщо не буде «під рукою» людини, з якою можна порадитись щодо реалізації, то робота може “встати”, ще не розпочавшись).

Але недаремно є приказка «терпіння і працю все перетруть».