Сообщений в теме: 7

[Boltick]

Недавно пришла в голову идея написания JAVA фреймворка-интерфейса-слоя между инструментом тестирования и самим тестом. Немного поиграв с кодом и взяв как основу 3 бесплатных инструмента Selenium, Watij, Htmlunit, я набросал прототип, который дает возможность писать тест независимо от инструмента тестирования.

Какие мы получаем бенефиты:
1. Один тестовый код может быть использован под разными инструментами (пока это Selenium, Watij, Htmlunit).
2. Наличие единых интерфейсов значительно упрощает сопровождение кода.
3. При переходе на новый инструмент добавляется лишь слой инстурмент-фреймворк, а слой фреймворк-тест остается без изменения.
и т.д.

Неудобства подобного НОВОГО фреймворка
1. Баги.
2. Отсутствие людей знакомых с ним
3. Недоверие к новинкам
и т.д.

В связи с этим у меня есть пара вопросов:

- Как вы считаете на сколько будет востребован подобный фреймворк?
- Как часто Вам приходится переходить с одного инструмента на другой?
- Хотите ли вы поучаствовать в разработке и дальнейшем развитии проекта?


Заранее спасибо за Ваши ответы.

[KaNoN]

Недавно пришла в голову идея написания JAVA фреймворка-интерфейса-слоя между инструментом тестирования и самим тестом. Немного поиграв с кодом и взяв как основу 3 бесплатных инструмента Selenium, Watij, Htmlunit, я набросал прототип, который дает возможность писать тест независимо от инструмента тестирования.

Какие мы получаем бенефиты:
1. Один тестовый код может быть использован под разными инструментами (пока это Selenium, Watij, Htmlunit).
2. Наличие единых интерфейсов значительно упрощает сопровождение кода.
3. При переходе на новый инструмент добавляется лишь слой инстурмент-фреймворк, а слой фреймворк-тест остается без изменения.
и т.д.

Неудобства подобного НОВОГО фреймворка
1. Баги.
2. Отсутствие людей знакомых с ним
3. Недоверие к новинкам
и т.д.

В связи с этим у меня есть пара вопросов:

- Как вы считаете на сколько будет востребован подобный фреймворк?
- Как часто Вам приходится переходить с одного инструмента на другой?
- Хотите ли вы поучаствовать в разработке и дальнейшем развитии проекта?


Заранее спасибо за Ваши ответы.

У меня есть опыт работы с аналогичным инструментом, который вы описываете. Но только он на Ruby. Имеется ввиду Webrat.
Судя по тому, что подобный инструмент еще живет, то определенная востребованность в нем есть.

В частности, подобное решение может быть полезно, если основной используемый тестовый фреймворк не может выполнить ряд операций, которые может выполнить другой тестовый фреймворк. Например, основным фреймворком является Watij, но некоторые операции лучше выполняются Selenium-ом, то возможность зарядить Selenium весьма кстати.

Теперь о недостатках, с которыми столкнулся я. У этих инструментов по-разному реализовывается механизм идентификации объектов. Соответственно, зачастую, если за основу берется один какой-то фреймворк, то такая вещь как инедтификаторы объектов зачастую затачиваются под этот фреймворк. И это в значительной мере нивелирует преимущества некоторой обертки над разными фреймворками.

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

С другой стороны, если вы учтете все типы подобных идентификаторов и сможете реализовать некое общее представление, то этот недостаток будет устранен.

Чуть более конкретно по вопросу, насколько часто приходится переходить из одного инструмента на другой:
Зачастую в пределах одного проекта переход от инструмента к инструменту происходит в случае серьезной ошибки выбора инструмента, когда инструмент не подходит где-то минимум на 30-40%. Но учитывая, что указанные вами инструменты по функциональным возможностям расходятся слабо, преимущество возможности смены фреймворка незначительно.

Оно куда более ощутимо в случае смены проекта, когда есть другой инструмент. Вот в этом случае остается стиль написания тестов, а различие лишь где-то на этапе инициализации движка.

[vass]

1) для JAVA ? почему бы и нет... для других - врядли такое получится.
2) Скорее этот фреймворк больше похож на спецификации "как писать более универсальные тесткейсы":) В принципе, это полезная штука, можно как-нить ее красиво назвать (Open Automated Testing Framework Specification) и продвигать в массы ;)

[Boltick]

Фреймворк именно под и для JAVA.

Сейчас немного подробностей.
1. Можно было сделать, как предложил KaNoN - взять за основу какой-либо инструмент и затачиваешь под него идентификаторы объекты других инструментов.
2. А можно сделать что-то свое: написать спецификации объектов исходя из каких-то определенных стандартов и реализовать слой, который бы работал с идентификаторами объектов инструментов через специфицированные свои объекты.

Я выбрал решение №2. - Так как прототип инструмента был предназначен для тестирования WEB, то я создал библиотеку HTML объектов на базе w3c спецификации. Далее были реализованы слои адаптации объектов для каждого отдельного инструмента на базе общего интерфейса ProxyBrowser, описывающего разные действия с/над объектами, такие как set, get, click, press и т.д.
И вуаля, прототип фреймворка готов. Первый шаг сделан.

Чтобы что-то пошло дальше нужно много рутинной работы, продолжать которую без должной мотивации очень сложно...

Вот.

[KaNoN]

1. Можно было сделать, как предложил KaNoN - взять за основу какой-либо инструмент и затачиваешь под него идентификаторы объекты других инструментов.

Маленькое уточнение - я это не предлагал, это просто наблюдения исходя из личного опыта использования аналогичного фреймворка. Просто зачастую получается, что базовых идентификаторов недостаточно, чтобы указать на нужный объект. В частности, в том же Webrat базовые идентификаторы опираются на label, id, name. Но когда дело доходит до css или xpath, то там надо немного поизвернуться и оказывается проще использовать уже синтаксис конкретной библиотеки.

[Stagor]

Кто-нибудь знает, где можно найти описание, как можно интегрировать Selenium с другим инструментом? Я сейчас работаю в этом направлени. Есть движок для описания тест скриптов в удобном формате, хотелось бы разработать порт для фреймворка, что бы можно было допустим описать тест скрипт с использованием Selenium'а, после чего, во время выполнения, фреймворк автоматически интерпретировал данный тест скрипт для Selenium'a, после чего обратно получал результаты, и генерировал общий и детальный отчет в соответствии с тест-кейс вставками тест скрипта.

Boltick, задумка отличная. Только для этого фреймворка надо еще продумать систему генерирования отчетов и внешний API для взаимодействия с ним.

[KaNoN]

Кто-нибудь знает, где можно найти описание, как можно интегрировать Selenium с другим инструментом? Я сейчас работаю в этом направлени. Есть движок для описания тест скриптов в удобном формате, хотелось бы разработать порт для фреймворка, что бы можно было допустим описать тест скрипт с использованием Selenium'а, после чего, во время выполнения, фреймворк автоматически интерпретировал данный тест скрипт для Selenium'a, после чего обратно получал результаты, и генерировал общий и детальный отчет в соответствии с тест-кейс вставками тест скрипта.

Selenium - это просто библиотека. Ее достаточно подключить и вызывать ее методы в тестовом коде. А во время выполнения нужно, чтоб был запущен Selenium-сервер. Вот и всё.

Boltick, задумка отличная. Только для этого фреймворка надо еще продумать систему генерирования отчетов и внешний API для взаимодействия с ним.

Вот это необязательно. Инструменты, которые пранируется объединить или "обернуть" в один интерфейс - это просто библиотеки для взаимодействия с тестируемым приложением, а генерация отчетов и вообще выполнение тестов - это в компетенции других библиотек, в частности TestNG или JUnit, у которых есть свой репортинг.

[Boltick]

Кто-нибудь знает, где можно найти описание, как можно интегрировать Selenium с другим инструментом? Я сейчас работаю в этом направлени. Есть движок для описания тест скриптов в удобном формате, хотелось бы разработать порт для фреймворка, что бы можно было допустим описать тест скрипт с использованием Selenium'а, после чего, во время выполнения, фреймворк автоматически интерпретировал данный тест скрипт для Selenium'a, после чего обратно получал результаты, и генерировал общий и детальный отчет в соответствии с тест-кейс вставками тест скрипта.

Selenium - это просто библиотека. Ее достаточно подключить и вызывать ее методы в тестовом коде. А во время выполнения нужно, чтоб был запущен Selenium-сервер. Вот и всё.

Boltick, задумка отличная. Только для этого фреймворка надо еще продумать систему генерирования отчетов и внешний API для взаимодействия с ним.

Вот это необязательно. Инструменты, которые пранируется объединить или "обернуть" в один интерфейс - это просто библиотеки для взаимодействия с тестируемым приложением, а генерация отчетов и вообще выполнение тестов - это в компетенции других библиотек, в частности TestNG или JUnit, у которых есть свой репортинг.

Полностью согласен с KaNoN...

Stagor, то что предложил я - это всего лишь слой между тестом и инструментом. Созданием отчетов должен заниматься инструмент (фреймворк), который запускает Ваши тесты и получает результат, допустим junit или TestNG...