У гонитві за якістю коду: Програмне тестування за допомогою Selenium і TestNG

  1. Серія контенту:
  2. Цей контент є частиною серії: У гонитві за якістю коду
  3. Тестування на відповідність вимогам користувача
  4. Програмне тестування з Selenium
  5. Налаштування першого тесту
  6. Лістинг 1. Конфігурація сервера Selenium
  7. Проходження додатки
  8. Лістинг 2. Проста HTML форма
  9. Лістинг 3. Прохід простий Web-сторінки
  10. Selenium і TestNG
  11. Малюнок 1. Форма для створення віджета
  12. Малюнок 2. Форма, що містить список, що розкривається
  13. Малюнок 3. Повернута Web-сторінка з інформацією про результат
  14. Сценарій тестування Create Widget
  15. Лістинг 4. Налаштовувана фікстура Selenium
  16. Лістинг 5. Значення параметрів у файлі TestNG testing.xml
  17. Лістинг 6. Стандартний сценарій тестування
  18. Лістинг 7. Використання TestNG
  19. Повторювані тести на відповідність вимогам користувача
  20. Використання DbUnit
  21. Детальна інформація про тест
  22. Лістинг 8. фікстур DbUnit для колекції тестів
  23. Лістинг 9. Специфічні параметри DbUnit, оголошені у файлі TestNG testing.xml
  24. Лістинг 10. Настроюваний файл testing.xml, який запускає фікстур DbUnit
  25. Cargo бере роботу на себе
  26. Управління тестовим контейнером
  27. Лістинг 11. Завдання для настройки Cargo
  28. Лістинг 12. Запуск і зупинка сервера Selenium
  29. Лістинг 13. Запуск тестів, виявлених у файлі testing.xml TestNG
  30. Ресурси для скачування

У гонитві за якістю коду

Виконувати автоматизоване тестування на відповідність вимогам користувача легшає

Серія контенту:

Цей контент є частиною # з серії # статей: У гонитві за якістю коду

https://www.ibm.com/developerworks/ru/views/global/libraryview.jsp?series_title_by=В+погоне+за+качеством+кода

Слідкуйте за виходом нових статей цієї серії.

Цей контент є частиною серії: У гонитві за якістю коду

Слідкуйте за виходом нових статей цієї серії.

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

Selenium також відрізняється від інших каркасів для тестування додатків тим, що дозволяє легко писати тести як програмістам, так і непрограмістів. У Selenium тести можна писати як програмно, так і використовуючи Fit-таблиці, а написані тести його можна повністю автоматизувати. Можна, наприклад, легко запустити весь набір тестів Selenium за допомогою ANT, а можна запускати тести Selenium в рамках середовища постійної інтеграції (continuous integration).

У цьому місяці я представлю Selenium і розгляну його функціональність, яка ставить її на особливе місце серед каркасів для тестування Web-додатків, особливо в комбінації з TestNG, DbUnit, Cargo і їм подібними.

Тестування на відповідність вимогам користувача

Оскільки Selenium відмінно підходить для моделювання поведінки користувачів, його зазвичай асоціюють з тестуванням на відповідність вимогам користувача, що має на увазі запуск наборів тестів на завершеною системі. Для ефективності подібних тестів зазвичай потрібна наявність повного ефектів у програмному забезпеченні. Якщо тестується Web-додаток, то потрібен доступ до бази даних програми, до Web-серверу, контейнеру і конфігураційним елементам, необхідним для виконання програми.

Програмне тестування з Selenium

У Selenium можна створювати тести програмно за допомогою мови за вашим вибором або Fit-таблиць. З точки зору тестування процес і його результати будуть мало відрізнятися, який би підхід ви не вибрали. Мене тут цікавить дослідження програмного підходу до Selenium, так як він дає цікаві можливості в поєднанні з TestNG.

Одна з переваг програмного використання Selenium з каркасом, подібним TestNG, в тому, що він дозволяє створювати інтелектуальні фікстура, що складно зробити за допомогою Fit-таблиць. TestNG особливо добре поєднується з Selenium, так як він може робити речі, неможливі в інших технологіях, такі як тестування з використанням залежностей, перезапуск невдалих тестів і створення параметризованих тестів з параметрами, визначеними в окремих файлах. Мати всі ці було б чудово для будь-якого середовища тестування Web-додатків, але ще краще, як ви побачите, мати можливість використовувати їх для повністю автоматизованого тестування на відповідність вимогам користувача.

Налаштування першого тесту

Архітектура Selenium в дійсності складається з двох логічних сутностей: код, написаний вами, і сервер Selenium, який допомагає взаємодіяти з тестованим додатком. Для успішного виконання тестів необхідна наявність працюючих екземплярів сервера Selenium та тестової програми. Результат тестів, звичайно, буде залежати від того, наскільки добре написано додаток.

На щастя, сервер Selenium - це невибагливий до ресурсів процес, який можна запускати і зупиняти програмно в рамках тесту. Запуск і зупинка сервера Selenium, реалізованого як об'єкт Selenium, є обов'язком фікстура.

Щоб програмно запустити сервер Selenium, потрібно створити новий об'єкт Selenium і сказати йому, який сумісний браузер потрібно використовувати; для даного прикладу використовувався Firefox. Також потрібно вказати, де запущений екземпляр сервера (зазвичай це localhost, хоча це не обов'язково) і основний URL для тестової програми.

У лістингу 1 я налаштував локальний екземпляр Selenium, щоб Firefox пройшов по локально встановленим Web-додатком (http: // localhost: 8080 / gt15 /). Як можна зробити висновок з аргументам, об'єкт Selenium діє як проксі для тестової програми і відповідно допомагає тестувати його.

Лістинг 1. Конфігурація сервера Selenium
Selenium driver = new DefaultSelenium ( "localhost", SeleniumServer.getDefaultPort (), "* firefox", "http: // localhost: 8080 / gt15 /"); driver.start (); // go to web pages and do stuff ... driver.stop ();

Коли об'єкт Selenium створений, його можна запускати і зупиняти методами start () і stop (), поки він працює. Це означає, що з сервером Selenium можна взаємодіяти програмно, змушуючи його виконувати процес тестування через браузер.

Проходження додатки

Програмне взаємодія з Web-сторінками - це вправа по використання логічних ідентифікаторів. Деякі читачі вже знайомі з цією концепцією по лютневої статті про TestNG-Abbot . Перший крок по взаємодії з елементом сторінки - це знайти його, для чого зазвичай використовуються ідентифікатори ID HTML елементів. Selenium також дозволяє за вашим бажанням використовувати для пошуку конкретних елементів XPath, регулярні вирази і навіть JavaScript.

HTML в лістингу 2 - це частина простого Web-додатка, що використовує Groovlet'и. У коді визначена одна форма, яка містить поле введення і кнопку підтвердження форми. Щоб використовувати Selenium для взаємодії з цією формою, потрібно надати ID для поля введення і відповідне значення для нього. Також потрібно надати ID для кнопки підтвердження, щоб Selenium зміг натиснути її. Після натискання форма відправляється на Groovlet, в даному випадку FindWidget.groovy.

Лістинг 2. Проста HTML форма
<Form method = post action = "./ FindWidget.groovy"> <table border = "0" style = "border-style: dotted"> <tr> <td class = "heading"> Widget: </ td> < td class = "value"> <input type = "text" name = "widget"> </ td> </ tr> <tr> <td> </ td> <td class = "value"> <input type = "submit" value = "Find Description" name = "submit"> </ td> </ tr> </ table> </ form>

Тепер можна програмно взаємодіяти з HTML формою, використовуючи ID widget для введення значення і submit для натискання кнопки, як показано в лістингу 3.

Лістинг 3. Прохід простий Web-сторінки
driver.type ( "widget", "pg98-01"); driver.click ( "submit"); driver.waitForPageToLoad ( "10000"); // assert some return value ...

API-інтерфейс Selenium для взаємодії з елементами Web-сторінок досить інтуїтивний. Для полів введення можна використовувати метод type (), щоб асоціювати значення з ID. Потім при необхідності можна програмно натискати (click) кнопки. У лістингу 3 я змушую Selenium чекати 10 секунд - цілком достатньо, щоб дозволити запитом на підтвердження форми завершити обробку. Після того як код в FindWidget.groovy виконає свою роботу і поверне відповідь, його можна використовувати для пошуку певних елементів сторінки і перевірки того, що все працює правильно.

Selenium і TestNG

Гнучкі і параметрізуемих фікстура TestNG роблять його відмінною "робочою конячкою" для визначення проведених Selenium тестів на відповідність вимогам користувача. Додавання здібностей TestNG за визначенням залежностей між тестами і перезапуску невдалих тестів, поза всяким сумнівом, робить комбінацію Selenium-TestNG беззаперечним переможцем.

Давайте почнемо з Web-додатки, що дозволяє користувачам створювати, шукати, редагувати або видаляти елементи графічного інтерфейсу (віджети). Для створення віджета потрібно три параметра: ім'я (name), тип (type), визначення (definition). Форма для створення віджета показана на малюнку 1.

Малюнок 1. Форма для створення віджета

Зверніть увагу, що елемент форми Type - це список, що розкривається з трьома можливими значеннями, як показано на малюнку 2.

Малюнок 2. Форма, що містить список, що розкривається

Натискання на кнопку "Create Widget" змушує Groovlet обробити запит. Якщо все нормально - ім'я і визначення заповнені і такого примірника ще немає в базі даних - то Groovlet створює новий екземпляр віджета і повертає сторінку з інформацією про результат, як показано на малюнку 3

Малюнок 3. Повернута Web-сторінка з інформацією про результат

Використання Selenium разом з TestNG для перевірки простого сценарію використання Create Widget (створення віджета) - це цілком здійсненне вправу.

  1. Налаштуйте та запустіть екземпляр сервера Selenium.
  2. Заповніть Web-форму Create Widget і відправте її.
  3. Перевірте, що повернута сторінка містить повідомлення про успіх операції з назвою віджета.
  4. Зупиніть екземпляр сервера Selenium.

Зауважте, що кожен крок в сценарії використання виконується через Selenium, TestNG тільки допомагає прокласти зв'язку, якщо можна так висловитися. Тепер давайте спробуємо це на практиці.

Сценарій тестування Create Widget

Я хочу зробити конфігурацію сервера Selenium гнучкою, так що я напишу параметризрвані фікстур в стилі TestNG-Selenium, яку потім можна буде використовувати, щоб створювати типові сервери Selenium для різних браузерів, різних місць розташування та навіть різних адрес Web-додатків, наприклад, localhost і робочої версії. Моя фікстура для настроюваного сервера Selenium представлена ​​в лістингу 4.

Лістинг 4. Налаштовувана фікстура Selenium
@Parameters ({ "selen-svr-addr", "brwsr-path", "aut-addr"}) @BeforeClass private void init (String selenSrvrAddr, String bpath, String appPath) throws Exception {driver = new DefaultSelenium (selenSrvrAddr, SeleniumServer.getDefaultPort (), bpath, appPath); driver.start (); } // .... @AfterClass private void stop () throws Exception {driver.stop (); }

Необхідно зв'язати назви параметрів зі значеннями в файлі testing.xml TestNG, так що я оголошую три елементи parameter, як показано в лістингу 5. За замовчуванням brwsr-path веде до Firefox, але можна з легкістю визначити новий набір тестів з використанням Internet Explorer.

Лістинг 5. Значення параметрів у файлі TestNG testing.xml
<Parameter name = "selen-svr-addr" value = "localhost" /> <parameter name = "aut-addr" value = "http: // localhost: 8080 / gt15 /" /> <parameter name = "brwsr- path "value =" * firefox "/>

Потім визначається сценарій тестування, показаний в лістингу 6, який також бере параметр з базовим URL до тестованого додатку. Цей тест змушує браузер відкрити конкретну сторінку всередині Web-додатки і провести ряд дій над формою, показаної на малюнку 1 .

Лістинг 6. Стандартний сценарій тестування
@Parameters ({ "aut-addr"}) @Test public void verifyCreate (String appPath) throws Exception {driver.open (appPath + "/CreateWidget.html"); driver.type ( "widget", "book-01"); driver.select ( "type", "book"); driver.type ( "definition", "book widget type book"); driver.click ( "submit"); driver.waitForPageToLoad ( "10000"); assertEquals (driver.getText ( "success"), "The widget book-01 was successfully created.", "test did not return expected message"); }

Після того як форма була підтверджена через метод driver.click ( "submit"), я змушую Selenium дочекатися завантаження відповіді і потім перевіряю наявність повідомлення про успішне створення. Зверніть увагу, що Web-сторінка з відповіддю має елемент з ID success.

Звівши все це разом, отримуємо настроюється варіант тестування, перевіряючий два сценарії: стандартний шлях і прикордонний стан, коли відсутня значення поля definition, як показано в лістингу 7.

Лістинг 7. Використання TestNG
public class CreateWidgetUATest {private Selenium driver; @Parameters ({ "selen-svr-addr", "brwsr-path", "aut-addr"}) @BeforeClass private void init (String selenSrvrAddr, String bpath, String appPath) throws Exception {driver = new DefaultSelenium (selenSrvrAddr, SeleniumServer.getDefaultPort (), bpath, appPath); driver.start (); } @Parameters ({ "aut-addr"}) @Test public void verifyCreate (String appPath) throws Exception {driver.open (appPath + "/CreateWidget.html"); driver.type ( "widget", "book-01"); driver.select ( "type", "book"); driver.type ( "definition", "book widget type book"); driver.click ( "submit"); driver.waitForPageToLoad ( "10000"); assertEquals (driver.getText ( "success"), "The widget book-01 was successfully created.", "test did not return expected message"); } @Parameters ({ "aut-addr"}) @Test public void verifyCreationError (String appPath) throws Exception {driver.open (appPath + "/CreateWidget.html"); driver.type ( "widget", "book-02"); driver.select ( "type", "book"); // definition explicitly set to blank driver.type ( "definition", ""); driver.click ( "submit"); driver.waitForPageToLoad ( "10000"); assertEquals (driver.getText ( "failure"), "There was an error in creating the widget.", "test did not return expected message"); } @AfterClass private void stop () throws Exception {driver.stop (); }}

Ми вже визначили два тести Selenium, досить гнучких, щоб полегшити тестування з декількома браузерами і декількома місцями розташування, що вже непогано для новачка. Переходячи на більш просунутий рівень, я хочу подумати про те, відтворена чи логіка в моїх тестах. Наприклад, що станеться, якщо запущу клас тесту CreateWidgetUATest два рази поспіль. Як я можу бути впевненим, що Web-додаток запущено на останній версії коду на моєму локальному комп'ютері або на будь-якому комп'ютері, якщо вже на те пішло.

Повторювані тести на відповідність вимогам користувача

І сервер Selenium, і перевіряється Web-додаток при запуску тестів Selenium повинні працювати. Мається на увазі, що повинні працювати і всіх залежних компоненти архітектури; для Java ™ Web-додатків це контейнер сервлетів і відповідна база даних.

Як я пояснював у статті про повторювані системні тести , Мої улюблені технології для реалізації логічної відтворюваності в залежних від бази даних Web-додатках - це DbUnit і Cargo. DbUnit управляє даними в базі, а Cargo автоматизує типові процеси управління контейнером. У наступних розділах буде показано, як поєднувати їх з Selenium і TestNG, щоб забезпечити логічну відтворюваність тестів на відповідність вимогам користувача.

Використання DbUnit

Ви, мабуть, пам'ятаєте, що DbUnit полегшує роботу з базами даних, керуючи даними в них в контексті сценарію тесту. За допомогою DbUnit можна завантажити відомий набір даних в базу перед тестом, що дозволяє бути впевненим у наявності цих даних під час тестування. Крім того, можна видалити з бази будь-які дані, створені в ході тесту, після його завершення. Технологія DbUnit спрощує ці завдання, виступаючи в якості зручною фікстура, придатної для використання в JUnit або TestNG. DbUnit зчитує файли шаблонів, що містять тестові дані, і логічно вставляє, видаляє або оновлює ці дані у відповідних таблицях бази.

Так як я використовую TestNG для управління Selenium, то я маю намір створити фікстур DbUnit, яка буде запускатися на рівні тесту. TestNG підтримує виконання фікстур на п'яти рівнях детальності. Нижні два рівня - рівні методу і класу - найбільш зрозумілі, фікстура призначені для кожного тестового методу або для цілого класу. Після них TestNG визначає фікстур для колекції тестів, визначених у конфігураційних файлах TestNG та зазначених елементом test, фікстур для цілого набору (suite) - колекції колекцій тестів, зазначеної елементом suite, і фікстур для групи тестів, визначених інструкцією Test з TestNG.

Детальна інформація про тест

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

Більш того, я хочу, щоб моя фікстура використовувала параметризрвані дані, що дають гнучкість в перемиканні файлів шаблонів і розташування бази даних, перед запуском кожного окремого тесту. Зв'язати параметри з TestNG дуже просто, все, що потрібно - це відзначити фікстур анотацією Parameters, оголосити відповідні параметри в сигнатурі методу і надати значення в файлі конфігурації TestNG.

У лістингу 8 наведено проста фікстура DbUnit, що заповнює базу даних з файлу шаблону. Відзначимо, що фікстура визначена так, щоб приймати п'ять параметрів. Можливо, це занадто багато, але хіба не зручно мати можливість задавати параметри для фікстура?

Лістинг 8. фікстур DbUnit для колекції тестів
public class DatabaseFixture {@Parameters ({ "seedpath", "db-driver", "db-url", "db-user", "db-psswrd"}) @BeforeTest public void seedDatabase (String seedpath, String driver , String url, String user, String pssword) throws Exception {IDatabaseConnection conn = this.getConnection (driver, url, user, pssword); IDataSet data = this.getDataSet (seedpath); try {DatabaseOperation.CLEAN_INSERT.execute (conn, data); } Finally {conn.close (); }} Private IDataSet getDataSet (String path) throws IOException, DataSetException {return new FlatXmlDataSet (new File (path)); } Private IDatabaseConnection getConnection (String driver, String url, String user, String pssword) throws ClassNotFoundException, SQLException {Class.forName (driver); Connection jdbcConnection = DriverManager.getConnection (url, user, pssword); return new DatabaseConnection (jdbcConnection); }}

Щоб прив'язати реальні значення до параметрами, наведеними в лістингу 8, потрібно визначити їх у файлі TestNG testng.xml, як показано в лістингу 9:

Лістинг 9. Специфічні параметри DbUnit, оголошені у файлі TestNG testing.xml
<Parameter name = "seed-path" value = "test / conf / gt15-seed.xml" /> <parameter name = "db-driver" value = "org.hsqldb.jdbcDriver" /> <parameter name = "db -url "value =" jdbc: hsqldb: hsql: //127.0.0.1 "/> <parameter name =" db-user "value =" sa "/> <parameter name =" db-psswrd "value =" "/ >

Настроюються параметрів

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

  • Необходимо, щоб фікстура DbUnit Виконала свою роботу до того, як буде запущена будь-яка колекція логічніх тестів.
  • Необходимо запускаті одну и ту ж колекцію тестів двічі, один раз для Firefox и один раз для Internet Explorer.

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

Наприклад, щоб запустити два набору тестів, я просто створюю два елементи test. Потім можна підключити фікстур і супутні тести через елемент package TestNG, який полегшує пошук всіх тестів (або фікстур) в структурі пакета. Потім можна зв'язати параметр brwsr-path з Firefox і Internet Explorer в двох певних группирующих елементах test. Все це показано в файлі testing.xml в лістингу 10.

Лістинг 10. Настроюваний файл testing.xml, який запускає фікстур DbUnit
<Suite name = "User Acceptance Tests" verbose = "1"> <! - required for DbUnit fixture -> <parameter name = "seed-path" value = "test / conf / gt15-seed.xml" /> <parameter name = "db-driver" value = "org.hsqldb.jdbcDriver" /> <parameter name = "db-url" value = "jdbc: hsqldb: hsql: //127.0.0.1" /> <parameter name = "db-user" value = "sa" /> <parameter name = "db-psswrd" value = "" /> <! - required for Selenium fixture -> <parameter name = "selen-svr-addr" value = "localhost" /> <parameter name = "aut-addr" value = "http: // localhost: 8080 / gt15 /" /> <test name = "GT15 CRUDs- Firefox"> <parameter name = "brwsr-path "value =" * firefox "/> <packages> <package name =" test.com.acme.gt15.Web.selenium "/> <package name =" test.com.acme.gt15.Web.selenium.fixtures " /> </ packages> </ test> <test name = "GT15 CRUDs- IE"> <parameter name = "brwsr-path" value = "* iexplore" /> <packages> <package name = "test.com. acme.gt15.Web.selenium "/> <package name =" test.com.acme.gt15.Web.selenium.fixtures "/> </ packages> </ test> </ suite>

Тепер можна сказати, що у нас є практично все необхідне для створення набору повторюваних тестів для перевірки вимог користувача. Все що залишилося - це навчитися управляти самим Web-контейнером. На щастя ми можемо використовувати Cargo.

Cargo бере роботу на себе

Cargo - це інноваційний проект з відкритим кодом, спрямований на розробку загальних методів автоматизації управління контейнерами. Наприклад, один і той же API дозволяє встановити War-файл на JBoss і може запускати і зупиняти Tomcat. Cargo також може автоматично завантажувати і встановлювати контейнер. API Cargo можна використовувати різними способами - від Java-коду до завдань Ant і навіть Maven.

Використання інструменту, подібного Cargo, вирішує одну з основних проблем написання логічних відтворюваних тестових сценаріїв - як уникнути звичайного припущення, що в занедбаному контейнері знаходиться остання і найкраща версія коду програми. Більш того, можна налаштувати процес складання (наприклад, в Ant), який за допомогою функціональності Cargo буде автоматично виконувати такі завдання:

  1. Завантажувати необхідний контейнер.
  2. Встановлювати контейнер.
  3. Запускати контейнер.
  4. Встановлювати обраний WAR або EAR файл в контейнер.

Потім можна використовувати Cargo для зупинки обраного контейнера. Більш того, немає необхідності турбуватися про викачування і установки контейнера - якщо на локальному комп'ютері вже встановлена ​​правильна версія, то Cargo пропустить кроки 1 і 2.

Я б хотів використовувати Cargo, щоб переконатися, що використовується остання і найкраща версія мого Web-додатки. Більш того, я не хочу турбуватися про те, де ви хочете помістити War-файл, так само як і про те, чи використовується самий останній War-файл. Що мені насправді потрібно - це зробити тестування на відповідність очікуванням користувача неінтерактивному (non-event), щоб можна було ввести одну команду, наприклад, ua-test, відкинутися назад і чекати результатів. Ще краще те, що в разі процесу з постійною інтеграцією не потрібно навіть нічого чекати, так як я просто отримаю повідомлення після завершення тестів.

Управління тестовим контейнером

Щоб налаштувати Cargo з Ant, необхідно визначити завдання, завантажувати конкретну версію Tomcat і встановлює його в тимчасовий каталог на локальному комп'ютері. Потім остання версія коду, упакована в WAR-файл, встановлюється в Tomcat, як показано в лістингу 11.

Лістинг 11. Завдання для настройки Cargo
<Target name = "ua-test" depends = "compile-tests, war"> <taskdef resource = "cargo.tasks"> <classpath> <pathelement location = "$ {libdir} / $ {cargo-jar}" / > <pathelement location = "$ {libdir} / $ {cargo-ant-jar}" /> </ classpath> </ taskdef> <cargo containerId = "tomcat5x" action = "start" wait = "false" id = " $ {tomcat-refid} "> <zipurlinstaller installurl =" $ {tomcat-installer-url} "/> <configuration type =" standalone "home =" $ {tomcatdir} "> <property name =" cargo.remote.username "value =" admin "/> <property name =" cargo.remote.password "value =" "/> <deployable type =" war "file =" $ {wardir} / $ {warfile} "/> </ configuration > </ cargo> <antcall target = "_ start-selenium" /> <cargo containerId = "tomcat5x" action = "stop" refid = "$ {tomcat-refid}" /> </ target>

Завдання (target) з лістингу 11 через елемент antcall викликає інше завдання. По суті, остання задача cargo в лістингу 11 служить оболонкою для завдання _start_selenium і гарантує, що Tomcat буде зупинений після тестів.

У задачі _start_selenium, визначеної в лістингу 12, потрібно запустити і потім зупинити сервер Selenium. До речі, мої тести також підключаться до цього сервера на своїх фікстур Selenium. Відзначимо також, що ця задача посилається на іншу задачу _run-ua-tests, певну в лістингу 13 .

Лістинг 12. Запуск і зупинка сервера Selenium
<Target name = "_ start-selenium"> <java jar = "$ {libdir} / $ {selenium-srvr-jar}" fork = "true" spawn = "true" /> <antcall target = "_ run-ua- tests "/> <get dest =" $ {testreportdir} /results.txt "src =" $ {selenium-srvr-loc} / selenium-server / driver /? cmd = shutDown "/> </ target>

Останнє завдання в групі реально запускає програмні тести Selenium через TestNG. Відзначимо також, що я змушую TestNG використовувати мій файл testing.xml, вказуючи xmlfileset в завданні _run-ua-tests з лістингу 13.

Лістинг 13. Запуск тестів, виявлених у файлі testing.xml TestNG
<Target name = "_ run-ua-tests"> <taskdef classpathref = "build.classpath" resource = "testngtasks" /> <testng outputDir = "$ {testreportdir}" classpath = "$ {testclassesdir}; $ {classesdir} "haltonfailure =" true "> <xmlfileset dir =" ./ test / conf "includes =" testng.xml "/> <classpath> <path refid =" build.classpath "/> </ classpath> </ testng> < / target>

Висновок

Як ви побачили, Selenium значно полегшує тестування на відповідність вимогам користувача, особливо коли він керується TestNG. Хоча програмне тестування - річ не для всіх, і непрограмістів віддадуть перевагу Fit-таблиці Selenium, воно дозволяє скористатися винятковою гнучкістю TestNG. Програмне тестування також дозволяє побудувати свою власну середу для тестування за допомогою DbUnit і Cargo, щоб забезпечити логічну відтворюваність тестів.

Еволюція каркасів тестування Web-додатків з відкритим кодом, звичайно ще не завершилася, що напевно порадує борців за якість коду. Технологія Selenium - один з перших open-source каркасів нового покоління для тестування Web-додатків за допомогою браузера, що автоматизують тести на відповідність вимогам користувача, і вже тому - видатний. Поєднуючи Selenium з TestNG, як я показав у цій статті, ви отримаєте відмінний тестовий механізм, разом зі значними перевагами тестування залежностей і параметризрвані тестування. Дайте шанс Selenium і TestNG, і користувачі будуть дякувати вас за це.

Ресурси для скачування

Схожі тими

  • Оригінал статті (EN).
  • Automate acceptance tests with Selenium (Christian Hellsten, developerWorks, грудень 2005 року): стаття знайомить із застосуванням Selenium для тестування на відповідність вимогам користувача з використанням Ruby on Rails і AJAX.
  • TestNG makes Java unit testing a breeze (EN) (Filippo Diotalevi, developerWorks, січень 2005 року): введення в unit-тестування за допомогою TestNG.
  • In pursuit of code quality: Repeatable system tests (EN) (Andrew Glover, developerWorks, вересень 2006 р): дізнайтеся, навіщо потрібні логічно відтворювані тести.
  • In pursuit of code quality: Automate GUI testing with TestNG-Abbot (EN) (Andrew Glover, developerWorks, лютий 2007 р): відкрийте для себе каркас для тестування, що вдихає нове життя в тестування компонентів графічного призначеного для користувача інтерфейсу.
  • In pursuit of code quality: Resolve to get FIT (EN) (Andrew Glover, developerWorks, лютий 2006 року): каркас для інтегрованих тестів (Framework for Integrated Tests - FIT) спрощує написання тестів для непрограмістів.
  • Control your test-environment with DbUnit and Anthill (EN) (Philippe Girolami, developerWorks, квітень 2004 року): використання DbUnit разом з JUnit дозволяє управляти процесом тестування навіть в системі постійної інтеграції (Continuous Integration).
  • Practically Groovy: Go server-side up, with Groovy (EN) (Andrew Glover, developerWorks, березень 2005 року): технологія Groovy пропонує простий альтернативний шлях швидкої і простої розробки серверних додатків.
  • Effective Unit Testing with DbUnit (EN) (Andrew Glover, OnJava, січень 2004 року): стаття знайомить з тестуванням, керованим базою даних, з використанням DbUnit.
  • An interview with Cargo's Vincent Massol (EN) (Andrew Glover, thediscoblog.com, лютий 2006): інтерв'ю, узяте Ендрю Гловером у Вінсента Масола (Vinsent Massol), засновника технології Cargo.
  • Hip system tests with Cargo (EN) (Andrew Glover, thediscoblog.com, квітень 2006 року): введення в Java API технології Cargo ..
  • Розділ Технологія Java на developerWorks : Cотни статей про всі аспекти Java програмування.
  • скачайте Selenium : Виконуйте тести на відповідність вимоги користувача безпосередньо через Internet Explorer або Firefox. (EN)
  • скачайте TestNG : Це настроюється каркас для тестування також може використовуватися для управління тестами Selenium (EN)
  • скачайте Cargo : Зробіть відтворюється тестування Web-додатків ще більш простим. (EN)
  • скачайте DbUnit : Встановлюйте базу даних в певний стан між запусками тестів. (EN)

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів

Jsp?
Можливо, це занадто багато, але хіба не зручно мати можливість задавати параметри для фікстура?
Txt "src =" $ {selenium-srvr-loc} / selenium-server / driver /?