Возможно, обязательно на него посмотрю. Я не претендую на уникальность. Этот модуль писался под мои нужды, и я подумал, что он еще кому-нибудь может быть интересен.
Я уже смотрел в сторону spock. Но, если честно, не вдохновляет. Если по существу, то, во-первых, одно другого не исключает, а скорее дополняет. А, во-вторых, spock — это груви, который далеко не всегда уместен.
Попиксельное сравнение в QTP есть, но это последний способ сравнения, который стоит применять. Удобнее и надежнее вытащить проверяемую информацию непосредственно из контролов.
DP — это не инструмент автоматизации, а техника обращения объектов в инструменте QTP.
Формулировка не совсем точная, согласен. Поправлю.
Автотесты нужны для регрессионного тестирования. Регрессионное тестирование — тестирование неизменного для данного релиза/патча/исправления функционала. Если меняется бизнес-логика — это значит изменился и функционал. В этом случае, естественно, что старые автотесты для данного участка не подойдут. Но полное изменение бизнес-логики бывает достаточно редко, согласитесь.
Возьмем пример: толстый клиент управления складом. Текущее количество бизнес-процессов, скажем 10. Заказчик хочет внедрить еще один процесс и изменить 2 существующих. В этом случае мы оставляем 8 автотестов в неизменном виде. Изменяем 2 (обычно изменения незначительные) и создаем один новый.
Для автоматизации десктоп приложений существует множество инструментов, в этом я с Вами согласен: и silktest, и testcomplete, и Ranorex и т.д. Но профессионально использовал только QTP и White. А я как-то не привык рекомендовать что-то о чем мало знаю :)
Ручному тестировщику тоже нужно будет сделать AJAX запрос к чашке кофе или в аську. :) Так что для него тоже приведен идеальный вариант. Автоматизация же не призвана ускорять приложение — для этого есть нагрузочное тестирование :)
Что касается TestComplete, то у него по сравнению с QTP есть один недостаток — «из коробки» он не интегрируется в HP (Mercury) Quality Center, который является практически отраслевым стандартом средств поддержки процесса тестирования в больших организациях. Сам по себе он, безусловно, хорош.
Для небанальных хомяков существуют коммерческие средства автоматизации. Например, упомянутые уже Testcomplete и QTP от HP. В селениуме мне понравилось наличие рекордера, что его как-то сближает с коммерческими инструментами. Некоторые вещи, как справедливо было замечено, можно делать очень быстро.
Правда и в коммерческих тулзах простые вещи делаются очень быстро, а сложные — как обычно :) Особенно часто это проявляется, если на странице есть «нестандартные» элементы управления, например, набор дивов, который выглядит и ведет себя как combobox. Помучиться пришлось изрядно %(
Прошу прощения, что влезаю, но это можно сделать и через REST API.
GET _apis/build/builds//timeline
Пример
Думаю дело в том, что:
Нет. Такие редьюсеры нужно, к сожалению, самому. Библиотека для простых редьюсеров — состояние как копия экшена.
Я не очень понял вопрос, какого апи и в чем проблема, что он не используется?
Экшны есть, просто их не нужно писать. Так же как и редьюсеры. Экшны создаются по конфигурации и соглашениям. Редьюсеры — на основе конфигурации.
Архитектура редукса не нарушается. Креаторы создают экшны, Мидлваре их передают, редьюсеры меняют состояние.
Свои middlewares я и писал по мотивам официальной документации. Но идея модуля в том, чтобы НЕ писать ни экшены, ни редьюсеры.
1. выбрать банк, вклады в котором застрахованы
2. Не держать одному человеку в одном банке более 700.000
Если открыты отдельные вклады в одном банке у мужа и жены, то в случае отзыва у банка лицензии до 700.000 будет выплачено по обоим вкладам.
Все вышеописанное справедливо для России.
DP — это не инструмент автоматизации, а техника обращения объектов в инструменте QTP.
Автотесты нужны для регрессионного тестирования. Регрессионное тестирование — тестирование неизменного для данного релиза/патча/исправления функционала. Если меняется бизнес-логика — это значит изменился и функционал. В этом случае, естественно, что старые автотесты для данного участка не подойдут. Но полное изменение бизнес-логики бывает достаточно редко, согласитесь.
Возьмем пример: толстый клиент управления складом. Текущее количество бизнес-процессов, скажем 10. Заказчик хочет внедрить еще один процесс и изменить 2 существующих. В этом случае мы оставляем 8 автотестов в неизменном виде. Изменяем 2 (обычно изменения незначительные) и создаем один новый.
Для автоматизации десктоп приложений существует множество инструментов, в этом я с Вами согласен: и silktest, и testcomplete, и Ranorex и т.д. Но профессионально использовал только QTP и White. А я как-то не привык рекомендовать что-то о чем мало знаю :)
С рекордерами в бесплатных тулзах, я боюсь, очень плохо, но попробую.
Что касается TestComplete, то у него по сравнению с QTP есть один недостаток — «из коробки» он не интегрируется в HP (Mercury) Quality Center, который является практически отраслевым стандартом средств поддержки процесса тестирования в больших организациях. Сам по себе он, безусловно, хорош.
Правда и в коммерческих тулзах простые вещи делаются очень быстро, а сложные — как обычно :) Особенно часто это проявляется, если на странице есть «нестандартные» элементы управления, например, набор дивов, который выглядит и ведет себя как combobox. Помучиться пришлось изрядно %(