Siesta - тестирование приложения

Для тестирования ExtJS (и не только), отлично подходит приложение Siesta. Она может производить тестирование как из окна браузера так и через командную строку. В данном примере будет показано использование Siesta через окно браузера.

Скачать Siesta можно вот отсюда.

Пример применения тестирования можно скачать вот отсюда . Открываем его в любом проекте Visual Studio, который сожно открыть в браузере. Данный проект состоит из:

  • Content - папка для хранения css стилей и изображений
  • MyApp - хранение произвольных данных, можно назвать как угодно
  • Scripts - javascript файлы. Здесь есть файл _reference.js - это специальный файл для работы с IntelliSense
  • test - папка для хранения тестов

Для запуска тестирования требуется запустить файл index.html

    

В первом примере unit-testing.t.js показаны примеры unit тестирования, а во втором как использовать ExtJS компоненты. Более подробно о тестировании можно узнать на сайте Siesta 

Эффективное тестирование

    Сокращение времени необходимого для запуска тестов, приводит к увеличению всего цикла развития приложения. Давайте посмотрим на некоторые методы для экономии времени при тестировании ExtJS приложения. Начиная с Siesta 2.1.0, появилось большое изменение - sandbox теперь необязателен. Это важно для модульных или Unit тестов, т.к они обычно выполняются очень быстро, потому что они сосредоточены на логике и им не нужно ждать отрисовки всего DOM (им не нужны щелчки мышью и пр.). Начиная с первого выпуска Siesta, тесты всегда были выполнялись в своих фреймах (песочницах). Эта особенность Siesta дает гарантию, что одни тесты не смогут оказать влияния на другие, например, изменив глобальные свойства браузера или глобальные переменные. Другая плюшка в том, что вам не нужно вручную очищать какие либо переменные среды (localstorage, global variables, ...) после ваших тестов. Таким образом, в целом, песочницы снижают входной барьер для новичков, позволяя легко начать писать тесты, но у этого подхода есть минусы. 

    Для каждого Unit-теста Siesta создает новый iframe и добавляет его на страницу, загружает ресурсы JS,CSS далее она ожидает загрузки DOM, потом выполняются onReady() в ExtJS, в конце теста происходит destroy iframe'a. Все в месте это выходит накладно, особенно для Unit-тестов, которые должны выполняться быстро. Другими словами, вышеописанный алгоритм, как правило, измеряется в секундах, в то время как сам тест может выполняться менее 100мс. В худшем случае это означает, что такие накладные расходы на выполнение теста будут составлять порядка 95% его времени выполнения. Ниже приведены методики для ускорения тестов.

   1.Песочница для группы тестов

Если группа тестов использует одни и те же preload файлы, и ни один из тестов не изменяет глобальные переменные и состояние браузера, тогда песочницу можно отключить. Ниже пример случая когда песочницу отключать не нужно (происходит изменение глобальных объектов):

// test1.t.js
StartTest(function(t){
    // "Helper" - config object
    Helper = { prop : 'value' },

    // Устанавливаем клобальный конфиг
    MyApp.someConfig = 'someValue',

    // Регистрируем Store
    var store = new Ext.data.Store({ storeId : 'store' })
})

Сразу можно заменить , первый тест создает две новые глобальные переменные и изменяет свойство MyApp. Это может вызвать проблемы, когда например послеющий тест выглядит так :

// test2.t.js
StartTest(function(t) {
    // "Helper" это класс ExtJS model 
    Ext.define('Helper', { .... })
 
    // ОШИБКА: "MyApp.someConfig" ожидается значение по умолчанию
    // но оно было изменено в ходе 1-го теста
    t.is(MyApp.someConfig, 'defaultValue', "`someConfig` has a default value")
 
    // Store с id `store` останется с 1-го теста
    t.notOk(
        Ext.data.StoreManager.get('store'),
        "Не должно быть Store с id=store"
    )
});

Как вы можете видеть, без песочницы прохождение тестов может вызывать потенциальные конфликты даже в простейшем коде. Большинство из этих проблем связаны с изменения глобальных переменных и синглтонов, но их можно избежать, делая дополнительную очистку в конце каждого теста. Если вы внимательны с общим состоянием, и ваши тесты полностью полагаются на локальные переменные в главной функции теста, вы можете отключить песочницу и значительно улучшить производительность тестов. 

    2. Оптимальный подход к UI тестам

Рассмотрим следующий пример :

При имитации пользовательского кода, моделирование событий ввода занимает много времени, в некоторых случаях его возможно заменить на более быстрый код c использованием API.

t.chain(
    { click : '>> textfield[fieldLabel=Name]' },
    { type : 'Имя' },
    { click : '>> textfield[fieldLabel=Password]' },
    { type : 'Qwerty123' },
    { click : '>> window[title=Login] button' }
)

Такой код имеет следующую излишне сложную логику, наведи курсор на поле, кликни по нему, введи данные потом нажми на логин. Оптимизированная версия выглядит так:

t.cq1('textfield[fieldLabel=Name]').setValue('Имя');
t.cq1('textfield[fieldLabel=Password]').setValue('Qwerty123');
t.click('>>window[title=Login] button');

Для сравнения неоптимизированная версия работает порядка 1.5 сек, оптимизированная лишь 30мс. Данный подход рекомендуется использовать везде где не нужно тестировать фактические нажатия на контролы.

    3. Отключение Siesta UI при запуске тестов.

При запуске тестов из консоли (например через PhantomJS) нет смысла отрисовывать интерфейс Siest'ы. Оставим лишь два скрипта необходимых для запуска тестов в index.html:



    4. Пауза между тестами

Что бы уменьшить нагрузку на IE (ранних версиях браузера < 8.0), Siesta добавляет паузу перед следующим тестом в 3сек (для того что бы garbage collector в IE успел отработать верно). Для других браузеров, вы можете уменьшить это значение до 1 секунды или даже 0, используя опцию --pause командной строки. 

Нет комментариев

Добавить комментарий