В інструменті TestComplete вже давно (починаючи з давніх версій) є модулі, що позиціонуються як ODT (Object-driven testing) і KDT (keyword-driven testing). Чи є ці модулі зручними для реалізації цих підходів або це просто гарна назва? Про це і поміркувати в цій замітці.
Все, що написано нижче - суто моя думка, засноване на 5-річному досвіді автоматизації на TestComplete, починаючи з версії 6.0 і закінчуючи останньою (на даний момент 9.10).
Пара слів про сам TestComplete
TestComplete - відмінний інструмент. В автоматизації desktop-додатків йому поки немає рівних, якщо брати до уваги ціну, поріг входження, зручність, функціональність. В останніх версіях (починаючи з 8.0) також дуже істотно була доопрацьована можливість автоматизації веб-додатків. Цілком можливо, що скоро TestComplete стане конкурентом WebDriver (у всьому, крім ціни).
Також дуже великий плюс інструменту - це підтримка таких технологій, як Flash, Flex, AJAX, Silverlight. Ну і інше (що, втім, є і в інших інструментах).
На відміну від того ж (конкурента) QTP, TestComplete, наприклад, дає можливість вибору скриптового мови: C ++, C #, DelphiScript, VBS, JScript. Не всі варто використовувати (про це напишу окрему замітку), але є вибір - це саме по собі вже плюс.
Також є повнофункціональний 30-денний тріал у версії Enterprise, що дуже зручно і добре.
модулі TestComplete
Під модулями я розумію ті речі, які можна додати до проекту в TestComplete. Це модулі в «широкому» розумінні цього слова.
Щоб зібрати тестовий suit і створити фреймворк, потрібно визначитися з модулями, які будуть використовуватися і зрозуміти, як саме ми їх хочемо використовувати. Змінити вибір в ключових модулях без істотного рефакторінга неможливо, тому це досить тонкий і важливий момент.
Якщо описувати кожен модуль окремо (якщо вистачить терпіння), то можна видати невелику книгу. Я опишу свою думку про два модулів: ODT і KDT, які часто використовуються і в використанні яких я бачив багато помилок на практиці.
Досить введення, поїхали
Розшифровується як Object-driven testing. Досить дивний термін. Ніде, крім TestComplete, я використання цього терміна не бачив. Є OOP, DSL, PageObject ... погуглити «ODT» - здивуєтеся, я думаю ... ODT в TestComplete в його класичному застосуванні - це сховище об'єктів - класів і даних. Зручне воно чи ні - про це нижче. Маленьке зауваження: якщо використовуєте термін ODT в спілкуванні, пам'ятайте - його знають тільки ті, хто знайомий з TestComplete.
Тут можна створювати класи. Навіщо? Думаю, основна задумка була в тому, щоб компенсувати «бідність» скриптових мов на предмет OOP. У Classes можна створювати класи та успадковувати одні класи від інших. Методи цих класів можна виносити в скрипти, прив'язуючи потрібну функцію як метод класу. Робити це можна як вручну (але ми ж автоматизаторів - це нецікаво і неефективно), так і з скриптів (це вже цікавіше).
Що дає створення класів в ODT.Classes?
- Можливість бачити доступні методи і властивості об'єктів після «точки» в процесі написання коду
- Можливість вручну описати якісь форми і об'єкти у вигляді класів
- можливість успадкування
- Можливість створювати структури тестових даних, тип яких дорівнює класу
Останнє - досить зручно (але про це нижче, в Data). Решта - досить спірне перевага, враховуючи мінуси використання Classes:
- Для автоматичного створення класів в ODT.Classes з скриптів потрібно описувати конструктори з усіма методами, і викликати ці конструктори. Тобто потрібен ще «збирач» всіх цих конструкторів. Також, імена методів передаються як рядки (дивіться код та опис нижче). Якщо якийсь метод перейменувався в коді і забув перейменуватися в конструкторі, помітити ви це можете дуже не відразу ...
- Розгортання спливаючого списку доступних методів і властивостей після «точки» досить сильно гальмує. Помітите ви це тільки на великому проекті, коли тестовий suit досить сильно виросте. Власне, коли міняти це вже буде дорого
Наприклад, щоб створити метод AddUser і властивість UsersCount в класі Users, потрібно написати такий код:
Як бачите, ім'я методу = UsersForm.AddUser і це рядок (ім'я файлу, де зберігається цей метод + ім'я методу).
На практиці я пробував використовувати ці класи з ODT. Але в підсумку недоліків було більше, ніж переваг і я переключився на використання класів мови JScript. Так, там немає успадкування, але і без нього можна побудувати хороший фреймворк (тим більше, що в ODT.Classes все одно немає інкапсуляції, поліморфізму і т.п. а є тільки спадкування, а з його єдиного розумну кашу зварити важко)
Створюємо клас (можна порожній)
Пишемо код для додавання потрібних об'єктів (з типом = цього класу) і потрібних властивостей
Розмір ODT.Data, як показала практика, не впливає на швидкість запуску і комфортність роботи (гальм, як при використанні класів, не помічав).
Висновок по ODT: використовувати можна, але не все і не завжди. Хороший варіант використання (один з можливих): ODT.Data для зберігання тестових даних і ODT.Classes для шаблонів об'єктів.
Keyword tests
KDT (Keyword-driven testing) за класикою - це досить однозначний підхід, який визначає як і де повинні проектуватися тести, і як сам фреймворк повинен співвідноситися з цими тестами.
Розробники TestComplete терміном «Keyword testing» досить непогано ухиляються від класики: це ж не keyword-driven testing, а keyword testing. І адже працює - багато хто починає плутати ...
Я опишу, що є в TestComplete і що повинно бути в нормальному KDT підході. А далі вирішувати Вам, використовувати цей модуль чи ні
Що вдає із себе модуль Keyword Testing в TestComplete:
- Візуальне середовище, що дозволяє створювати тест «мишкою», без написання коду
- Набір Checkpoints для різного роду верифікації (полів введення, таблиць, картинок, сервісів і т.п.).
- Інтерактивні вікна в ході запису тесту або додавання checkpoint
- Vizualizer, що дозволяє додати верифікацію в потрібне місце в уже існуючий тест (зберігає всі вікна, які використовувалися під час запису тесту і дозволяє потім «заднім числом» вибрати потрібний контоль і додати на нього верифікацію, наприклад)
Можна робити виклики інших, вже готових, keyword-тестів, а також скріптові рутини. В принципі, обмежень по функціоналу цей модуль не має. Але є одна особливість: це не keyword-driven тестування, це - просто візуалізація і полегшення життя на початкових етапах вивчення автоматизації.
Що вдає із себе підхід KDT (keyword-driven testing):
- Можливість писати тести поза середовищем розробки (кейворд-тести часто пишуть бізнаса-аналітики або люди від замовника, які відмінно знають домен, але не розбираються в автоматизації)
- Словник з кейвордов, який використовується для складання тестів
- Фреймворк, який реалізує можливість використання кейвордов (фреймворк часто не видно тим, хто складає тести з кейвордов. Це і не потрібно: такий поділ робиться спеціально, щоб відокремити групу розробки фреймворка від групи осіб, які будуть складати тести)
Що з цього є в TestComplete? Нічого. Писатимуть тести поза TestComplete неможливо; словник є, але дуже обмежений (checkpoints), всі інші кейворди потрібно описувати (що логічно, в принципі); фреймворк також потрібно розробляти самостійно.
Чи надає TestComplete можливість спростити створення фреймворка або якісь шаблони для складання повноцінного KDT? - Ні.
Висновок: реалізувати підхід KDT в TestComplete можна. Але те, що вийде на виході, не матиме нічого спільного з модулем Keyword testing
Відповідаючи на питання з заголовка
ODT і KDT в TestComplete: міф чи реальність?
ODT: на 50% міф, на 50% реальність. Міф з точки зору ODT.Classes, які на практиці використовувати досить незручно і вони не дають будь-яких істотних переваг (в порівнянні з класами в мовах, наприклад, JScript). У ODT.Data можна реалізувати спадкування, але його користь досить ілюзорна, враховуючи описані вище недоліки. ODT.Data використовувати можна і потрібно - зручне сховище тестових даних. У зв'язці з класами-шаблонами дозволяє створити комплексну структуру тестових даних, що зручно для автоматизації.
KDT: міф. Є модуль Keyword testing, який не має нічого спільного з підходом keyword-driven testing. Класичний KDT реалізувати можна, але для цього потрібно писати код і проектувати фреймворк. Втім, будь-яка серйозна автоматизація має на увазі фреймворк, так що це не повинно лякати.
Як на практиці реалізувати підходи ODT і KDT?
На тренінгу «Підходи до розробки тестового фреймворка (TestComplete)» ми детально розберемо кожен з підходів: object-driven testing (ODT), data-driven testing (DDT), keyword-driven testing (KDT), навчимося їх реалізовувати з нуля і зрозуміємо , які підходи підходять краще для вирішення різних практичних задач.