Основные фишки:
быстрота создания типовых действий (перетаскивание мышкой),
автотест является скриптом на языке программирования Clojure
поддержка xpath, json (удобная генерация xpath,jsonpath по примерам сообщений)
поддержка ssl,
поддержка любых сторонних java библиотек и jms провайдеров.
Интересно мнение, профессионального сообщества. Что думаете?
Спасибо за ответ.
Был бы рад если бы вы или ваши коллеги попробовали приложение.
Готов регулярно вносить улучшения/новый функционал основываясь на отзывах.
Это не только набор окон, это domain-specific programming language для создания функциональных тестов.
Окна нужны, чтобы для создания простейших тестов не требовалось знание какого-либо языка программирования, и не было необходимости держать в голове АПИ различных библиотек. Интерфейс постарался сделать интуитивным.
При этом для более опытных пользователей есть возможность писать код напрямую (вкладка source), (подсветка синтаксиса присутствует, в планах добавить автодополнение). (Код в любой момент можно визуализировать, и наоборот визуализацию представить в виде кода) Добавив свою имплементацию “типовых действий” я постарался сделать DSL для функционального тестирования поверх Clojure. Т.е. постарался сделать вызов функций таким какой он был бы удобен именно для создания функциональных тестов, а не для программирования. (Обычно фреймворки для языков программирования заточены на перфоманс, в Java, например, вас просят сначала распарсить xml, получить DOM документ, затем создать объект xpath и только потом получить по нему значение, что загромождает код). Чтокасается Питон’а нужно смотреть на конкретных примерах. Я всегда готов улучшать приложение и DSL на котором создаются тесты.
Вот кстати. Хотел сейчас скачать, но остановило то, что обязательна Java 8. А я пока не ставил себе да и не особо планировал еще.
Понятно, что нужно типа “двигаться в ногу со временем”, но всё же.
На сайте присутствует сборка под Windows (на первой странице внизу), не требующая java.
В будущем планирую добавить готовую сборки для MacOs
и пакет для linux с зависимостями. Если есть спрос
У меня как раз mac.
Просто может не стоило так уж гнаться за модой и делать какие-то вещи, специфичные для 8ой версии. Мало ли кто захочет воспользоваться Вашим инструментом.
Сама идея достаточно интересная, в принципе, хорошо что вы поделились проектом на ранних стадиях.
Несколько вопросов:
Почему closure? – Я думаю, что это не самый мейнстримный язык для автоматизации. Почему не C#, Java, JavaScript, Ruby, Python?
Этого достичь не получилось. Даже в примере вы что-то дописываете на кложуре. Т.е. без знания языка программирования, быстро набросать тест никак не получается. А если я знаю язык программирования – то мне этот инструмент не зачем.
Отчет о прогоне теста не информативен
Баги (Win7):
При каждом запуске (kangaroo_v1_2_0b.bat) приложение предлагает дефолтный путь к проекту в папке Temp. Выглядит странно
Мой вывод:
Я думаю, что вам нужно продолжить работу над идеей, но текущая реализация никуда не годится.
Начните с анализа тех инструментов, которые уже давно на ранке и попробуйте понять, чем вы можете быть лучше. С ходу, в голову приходит Testcomplete, там есть что-то вроде визуального кода.
Большое спасибо за ваш ответ.
Информативность отчетов действительно следуеют доработать.
Дефолтный путь к проекту стоит выставлять предыдущей?
Cогласен с Вашими замечаниями.
Этого достичь не получилось. Даже в примере вы что-то дописываете на кложуре.
В примере я это делаю, только чтобы продемонстрировать что такая возможность есть. (Базовыми средствами делается сравнение некого значения с эталоном, во втором случае проверяется на истинность некое выражение на clojure)
Почему не C#, Java, JavaScript, Ruby, Python?
Изначально решил что будет очень полезной если приложение будет работать JVM - так как java и java-технологии (например jms) очень распространены в распределённых приложениях (тестирование которых и предполагается). Для java существует много библиотек подключение которых может понадобится для тестирования очень кастомного решения. (В том числе опытный тестировщик может дописать её сам и подключить в Kangaroo)
Clojure - работает на jvm, и совместим с любыми классами и библиотеками java.
У него нет никакого синтаксиса (по сути это старый добрый Lisp на jvm с макросами)
что позволяет делать на нём свой доменный язык для прикладной задачи (функциональное тестирование), функциональность языка будет полезна, для простоты описания и запуск из тестов “сервисов-заглушек” (добавлю в будущем если, будет спрос). Код на clojure - очень просто парсить и конструировать, что и позволяет иметь взаимно однозначное отображение код-визуализация.
В soapUI - насколько помню Groovy, а в JMeter и подавно - свой синтаксис, тем не менее люди активно используют эти продукты, или это немного другая сфера?
Будучи разработчиком, которому на работе часто требуется проверять интеграцию в распределённых приложениях, я испытываю на себе высокий порог входа в профессиональные продукты. Такие продукты как soapUI с его обилием настроек, окон, вводит в ступор. Первой целью было создать приложение - для которого не нужна документация, которое было бы “сподручным” для человека которому нужно сделать простейшие действия (и только в случае чего-то сложного требовалось бы обращаться к документации). Например в Jmeter - решительно невозможно сделать что либо без документации. Хотелось бы занять такую нишу, постепенно добавляя функционал, который бы мог сравниться с возможностями больших, “громоздких” продуктов.
На самом деле, сам синтаксис для Clojure учится буквально несколько минут. (Дольще осваивается парадигма функционального программирования, для которого он создан, но в подавляющем большинстве случаев для написания функциональных тестов, углубятся в это просто не будет необходимости). Зато пользователи получили приятный бонус: Kangaroo автоматически умеет определять, что вводимый пользователем текст в полях форм - является кодом (например вызов функции или подстановка некой константы), а не просто неким текстовым значением (поле в этом случае подсвечивается фиолетовым цветом). С другими языками точно определять скорее всего не получилось бы. Ну и интерес к функциональным языкам (Clojure,Scala, Haskell) в последнии годы растёт, возможно что инвестиции времени в опыт на Clojure ещё ни 1 раз окупятся
Ну, возможно. Надо поподобнее изучить вопрос.
Заметил ещё одну штуку. Не хватает нормальных результатов прогона. Сейчас получается, что-то типа ручного тестирования. Надо бы чтобы можно было запускать несколько сценариев и предоставлять результаты прогона в нормальном читабельном виде.
testomat.io управление авто тестами
Распространёность groovy и порог вхождения в него, мне кажется, более приемлемы.