Все же мы тестируем высокоуровневый функционал, то, как компоненты ведут себя вместе, как они реализуют системный функционл. А ещё тестируем сложные цепочки вызовов, которые не из интерфейса сложно проверить. Ну и гарантируем то, что версия продукта не будет иметь очевидных проблем с точки зрения конечного пользователя (на покрытых участках, естественно).
В общем мы не проверяем сами компоненты ExtJS. Ну, проверяем конечно, но это побочный эффект. Нам важно чтоб пользователь мог выполнить задачу, а то что компоненты работают верно — эффект побочный.
Так вот, тесты во время выполнения делают инъекции в тестируемый код *увернулся от помидорки*. Правда очень ограниченные, и эти инъекции не должны изменить логику тестируемого стенда.
В частности для AJAX, перед вызовом добавляется подписчик, который регистрирует этот вызов в глобальной коллекции. А по выполнению (или на отказ) вешается другой подписчик, который во первых изменяет состояние глобальной коллекции, а во вторых зачищает за собой весь мусор.
Таким образом мы пуляем событие на выполнение AJAX (жмем кнопку, обновляем список и т.п.), и после этого начинаем долбить Selenium-ом браузер на предмет завершенности запроса в данной глобальной коллекции. Выходит что нам не важно что должно будет прийти на AJAX запрос (а там такой адЪ приходит порой), нам важно чтоб в принципе запрос завершился. И нам не надо ждать больше положенного. Соответственно пока Selenium не убедился что запрос закончен, он не передает управление прикладному коду теста. Это упрощает тест. Разработчику теста даже не надо думать что его кнопочка что-то там куда-то услала, он просто проверяет что после того, как нажал кнопочку появилось окошко с надписью «Учапу»! И это прекрасно ^_^ А ещё мы вместо тестера перехватываем все технические ошибки (запрос не прошел, вернулся не тот формат, требуется аутендификация и т.п.).
Все же мы тестируем высокоуровневый функционал, то, как компоненты ведут себя вместе, как они реализуют системный функционл. А ещё тестируем сложные цепочки вызовов, которые не из интерфейса сложно проверить. Ну и гарантируем то, что версия продукта не будет иметь очевидных проблем с точки зрения конечного пользователя (на покрытых участках, естественно).
В общем мы не проверяем сами компоненты ExtJS. Ну, проверяем конечно, но это побочный эффект. Нам важно чтоб пользователь мог выполнить задачу, а то что компоненты работают верно — эффект побочный.
Так вот, тесты во время выполнения делают инъекции в тестируемый код *увернулся от помидорки*. Правда очень ограниченные, и эти инъекции не должны изменить логику тестируемого стенда.
В частности для AJAX, перед вызовом добавляется подписчик, который регистрирует этот вызов в глобальной коллекции. А по выполнению (или на отказ) вешается другой подписчик, который во первых изменяет состояние глобальной коллекции, а во вторых зачищает за собой весь мусор.
Таким образом мы пуляем событие на выполнение AJAX (жмем кнопку, обновляем список и т.п.), и после этого начинаем долбить Selenium-ом браузер на предмет завершенности запроса в данной глобальной коллекции. Выходит что нам не важно что должно будет прийти на AJAX запрос (а там такой адЪ приходит порой), нам важно чтоб в принципе запрос завершился. И нам не надо ждать больше положенного. Соответственно пока Selenium не убедился что запрос закончен, он не передает управление прикладному коду теста. Это упрощает тест. Разработчику теста даже не надо думать что его кнопочка что-то там куда-то услала, он просто проверяет что после того, как нажал кнопочку появилось окошко с надписью «Учапу»! И это прекрасно ^_^ А ещё мы вместо тестера перехватываем все технические ошибки (запрос не прошел, вернулся не тот формат, требуется аутендификация и т.п.).
Вот как-то так.