Про тестовий фреймворк замовте слово…

Mon, 10 Nov 2014 12:13:16 +0200

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

Не знаю, як для кого звучить згадка про тестовий фреймворк, але для мене, перш ніж став «тісно» працювати над автоматизацією слова когось на конференції/у відео-уроці «Я написав свій тестовий фрейморк» викликали шанобливу повагу та «тремтіння у колінах». Що цілком легко зрозуміло було, оскільки знань з програмування та розуміння того, з чим доведеться працювати було замало і по суті фраза сприймалася як «я написав свій ще крутіший варіант 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();

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

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

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

<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 і паралельне виконання тестів наближається. Звичайно не варто «відразу писати тести по всьому»: покрийте базову функціональність, основні сценарії, а потім приступайте до детальніших перевірок «всього». Природно, що тестових даних буде багато, а значить один і той же сценарій працюватиме на багатьох наборах даних (які читатимуться їх файли, бази даних, генеруватимуться «на льоту» залежно від контексту). Роботи багато, часу на реалізацію займе багато, особливо якщо з мовою програмування «на Ви» (про те, яку мову вибрати – теж треба подумати заздалегідь: якщо не буде «під рукою» людини, з якою можна порадитись щодо реалізації, то робота може “встати”, ще не розпочавшись).

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

Запрацювало!

Wed, 28 Aug 2013 11:05:20 +0300

Ура! Нарешті запрацювало!
… або Переходимо до Page Object Pattern

… Вирішив переробити структуру проекту автотестів із “банального” (але працюючого!:)) варіанта
Constants <- Helper <- Test <-Runners
в
Helper <- Modules; Tests (Helper, Modules)
де Modules – окремі класи (файли) для різних сторінок програми, Tests (Helper, Modules) – окремі класи (файли) для тест-сьютів для кожного окремого модуля (сторінки), що використовують методи з базового класу Helper та спадкоємців Modules. Та ось невдача: знань з основ програмування на C# не вистачало. Після кількаденного танцю із бубнем та переписування всього, консультацій з хлопцями-програмістами з проекту вийшло ось що у файлі тестів

{
    public TestsFirefox(): base(new FirefoxDriver())
    { }
}

public class TestsIE : TestsCases2TS
{
    public TestsIE(): base(new InternetExplorerDriver())
    { }
}

public TestsCases2TS(IWebDriver browser): this()
{
    Helper.driver = browser;
}

public TestsCases2TS()
{
    myHelper = new Helper();
    myModule = new Module();
    myHelper.baseURL = Helper.testServerBaseUrl;
    myHelper.verificationErrors = new StringBuilder();
}
public Helper myHelper { get; set; }
public Module myModule { get; set; }

І ось ЦЕ запрацювало!:) (власне, описи тестів та методів у самих файлах залишилися майже без змін)

Але більш докладно розібратися з конструкторами, інкапсуляцією та іншими радощами реалізації ООП в C# мені ще належить…

Page Object Pattern on jUst QA blog

Про тестовий фреймворк замовте слово…

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

Запрацювало!