Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Chromium Embedded Framework — Autotesting howto

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

«..Знайшов прикольну статтю, в якій автор описує як..»

Приблизно так починається типовий допис на тему заглиблення в нетрі якоїсь в міру задротистої технології. Але не цього разу :)

Сьогодні поведемо мову про CEF. Хтось знає як писати автотести для CEF? Ба більше — хтось взагалі знає що таке CEF? :) От і я не знав. І ви думаєте знайшов «..прикольну статтю, в якій автор..»? Дулі! Жодної! Хоча, це не зовсім правда, якщо статтею можна вважати wiki сторінку 7-річної давнини.

Що ж робити?

Правильно! Писати свою статтю :)

По-перше, що таке CEF?

Це Chromium Embedded Framework. Ключове слово — «Embedded». Спрощуючи — це браузер, вбудований в інший додаток.

Навіщо CEF?

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

Так і що там з тестуванням?

Якщо ведеться про ручне тестування — то жодних проблем, black-box тестується так само як і будь який інший додаток. CEF навіть підтримує порт для дебагу, тобто можна подивитись що там всередині за допомогою Chrome Dev Tools — і ось це вже важливо! Далі буде зрозуміло чому.

Якщо ж постає задача писати автотести для додатку з CEF, то перше що приходить в голову — старий-добрий Selenium WebDriver. Точніше ChromeDriver. У випадку з браузером все зрозуміло: ініціалізували драйвер — запустився браузер і можна з ним працювати через об’єкт драйверу. А от з CEF — ініціалізація драйвера нічого не запускає. Потім, навіть якщо ви запустите додаток, який містить CEF, якимось іншим чином, то проста ініціалізація драйвера все ще не надасть вам можливості працювати з CEF.

Howto (або 5 питань щоб розпочати автоматизацію тестів для CEF):

1) Реалізація. Вочевидь є різні реалізації CEF під різні платформи. В моєму випадку я працюю з Windows Desktop додатком, написаним на WPF. Тому й вибір реалізації CEF розробниками був віподвідний: CEFSharp. Для інших платформ це будуть інші бібліотеки, яка саме — важливо знати, бо є різні нюанси в роботі з ними.

Як дізнатись: спитати в розробників (або ж накрайняк подивитись найпопулярнішу бібліотеку для вашої платформи, з ймовірністю 99% саме вона й використовується, бо їх в принципі не дуже багато).

2) Версія. Переконайтесь що ваш chrome driver в проекті з автотестами має таку ж версію, як chromium embedded framework у тому додатку, тестування якого ви автоматизуєте.

Як дізнатись: знову ж таки — спитати у розробників, або, наприклад у моєму випадку з CEFSharp — подивитись властивості dll файлика «CefSharp.BrowserSubprocess.Core.dll».

Відповідно chrome driver в проекті має виглядати так:

3) Debugging port. Щоб працювати з CEF всередині вашого додатку, ваш chrome driver в автотестах має «підключитись» до вже запущеного додатку. Для цього додаток має бути запущений з ввімкненим портом для дебагу, власне це саме той інтерфейс яким ви користуєтесь працюючи з Chrome Dev Tools.

Як зробити: є різні способи це зробити, найпоширеніший й найпростіший — просто додати параметр в команд-лайні при запуску додатку, наприклад:

cefapp.exe -remote-debugging-port=8081

Але у випадку з CEFSharp не все так просто. Вказаний параметр в командному рядку не ініціалізує cef debug port. Як з’ясувалось, для того щоб працювати з Debugging Port в CEFSharp додатку треба перезібрати ваш додаток, із додаванням декількох рядків конфігураційного коду:

var settings = new CefSettings();
settings.RemoteDebuggingPort = 8081;
Cef.Initialize(settings);

4) Запуск додатку.

Моя проблема з пошуками інформації полягала в тому, що те що я знайшов було написано для «стандартної» реалізації CEF, й не працювало в CEFSharp. Наприклад, в «стандартній» реалізації є можливість запустити тестований додаток при ініціалізації chrome driver у ваших автотестах, це робиться так:

ChromeOptions options = new ChromeOptions();
options.BinaryLocation = @"C:\temp\CefSharpExample\cef_app";
driver = new ChromeDriver(options);

Але, нажаль з CEFSharp цей підхід не працює. Тестований додаток доведеться запускати звичайнісіньким

Process.Start(“c:\\temp\\cefsharp_app”);

5) Підключення до Debug Port.

Коли ж всі попередні не дуже очевидні кроки виконані — лишається лише підключитись до debugging port при ініціалізації вашого chrome driver у ваших тестах:

ChromeOptions options = new ChromeOptions();
options.DebuggerAddress = "localhost:8081";
driver = new ChromeDriver(options);

PROFIT!!!!

Тепер ось всі ці ваші driver.FindBy працюють як треба!

Бонус proof-of-concept (на погратись)

CEFSharp demo app: github
CEFSharp Selenium proof-of-concept: github

P.S. А ще ми з друзями ведемо телеграм канал про тестування t.me/qamania — заходьте, ми намагаємось щодня писати щось цікаве про нашу професію

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Прочитавши, я так і не зрозумів: навіщо взагалі юзати цей CEF? В чому профіт і яку він проблему вирішує?

Головна ідея цього допису — надати можливість тестувальникам, яким все ж таки довелось познайомитись з CEF (якщо бути точним — з CEFSharp), не наступити на ті самі граблі що й мені. Просто тому що матеріалів на цю тему майже немає.

В такому разі це круто, хорошу справу робите!

Embedded, который мы заслужили.

Підписатись на коментарі