Здравствуйте, друзья!
Предлагаю вашему вниманию небольшую конфигурацию для сценарного тестирования решений на базе 1С:Предприятие 8.3, управляемые формы.
Конфигурация называется Тестер. Тестер является средой разработки и запуска сценарных тестов. Тестер не является продуктом BDD в чистом виде и не предназначен для описания поведения системы, до того, как она была разработана.
Главные цели Тестера:
- Организовать коллективную работу с тестами в единой среде с поддержкой версионности, захвата на редактирование и других привычных функций по работе с кодом
- Предоставить пользователю лёгкий способ создания, поддержки и расширения реальных сценарных тестов, в разумные сроки, с минимальным порогом вхождения в процесс, и надежной инфраструктурой
Используя тестер, вы можете рассчитывать на решение следующих задач:
- Высокая степень покрытия функционала. Тестер хорошо сфокусирован на процесс разработки тестов, что положительно сказывается на количестве и качестве создаваемых тестов
- Тесты пишутся на языке программирования 1С, что является не только знакомым инструментом, но также позволяет использовать в тестировании весь набор функций платформы, а главное – позволяет управлять ходом тестирования программно, не опираясь на заложенную модель в инструменте тестирования
- Из тестов можно делать библиотеки, например, можно создавать тесты, которые по переданным параметрам открывают окно поиска в динамическом списке, или формируют некий отчет. Если вам нужно для своего теста иметь остаток на складе, можно реализовать библиотечный тест, в который вы передадите состав требуемого остатка, и этот остаток будет оприходован
- Простая проверка бизнес логики, без сравнения с данными других баз, без прямых запросов к тестируемому приложению, без макетов с сериализованными «в другом месте» данными. Вся информация может быть сохранена в самом тесте, в макете, при необходимости – доработана.
- Кроме того, что все тесты хранятся в базе, и любой пользователь Тестера может использовать написанный другим программистом тест, Тестер имеет возможность инкрементальной выгрузки/загрузки тестов в файловую систему. Это может быть полезно для дальнейшей синхронизации тестов с системами контроля версий, например, Git.
Красивые слова можно проверить на деле. Конфигурация и демонстрационная база расположены здесь https://github.com/grumagargler/tester.
В демонстрационной базе разработана небольшая инфраструктура взаимосвязанных тестов, которая может быть взята на вооружение при разработке ваших собственных тестов. Также, в базе есть пример создания документа Заказ поставщику для ERP2 (демо).
Для конфигурации ERP2 (демо), был создан репозиторий https://github.com/grumagargler/ERP2
Туда я выгрузил демонстрационные тесты. Надеюсь, это начинание не останется без внимания энтузиастов, и тесты будут пополняться.
Наиболее исчерпывающую информацию по Тестеру вы найдете в справке, она будет на рабочем столе, при запуске системы. В справке есть раздел Быстрый старт, я рекомендую с ним ознакомиться.
Тестер бесплатный. Разрабатывается и поддерживается для собственных нужд, без какой-либо коммерческой подоплеки.
Спасибо за проявленный интерес к системе и удачных вам тестов друзья!
Обновление 1.3.2.7
— Добавлена процедура LogError (ЗаписатьОшибку), используется для программного добавления сообщений в журнал ошибок из кода сценария без остановки выполнения сценария
— Все функции по работе с полями теперь умеют производить навигацию по табличной части, например, так можно проверить в пятой строке сумму начисления: Проверить ( «#Начисления / Результат [ 5 ]», 1000 );
— Функция Check (Проверить) пытается проверять числовые значения без учета разделителя триад и дробной части
— Добавлен Журнал запуска, где регистрируются события выполнения сценариев
— Добавлен переход из сценария в Журнал запуска и Журнал ошибок
— Добавлена регистрация «последнего автора» для сценариев
— Добавлен помощник в дерево выбора полей
— В помощник добавлена онлайн-справка по встроенным методам тестера
— Добавлены версии приложений. Версии могут задаваться как для приложения в целом, так и отдельно для каждого пользователя
— Добавлены отчеты: Протокол, Сводка (отчеты будут работать только для вновь запущенных сценариев данного релиза). Существует возможность настройки расписания отсылки отчетов по почте (при формировании отчетов учитываются RLS пользователей)
— Отчеты реализованы в виде отдельных прав, для их добавления пользователям-не-администраторам, нужно произвести соответствующие настройки в их профилях
— Оптимизирована выгрузка сценариев в файлы. Выгружаемые файлы формируются в формате bsl
Порядок перехода:
После обновления конфигурации, перед запуском на выполнение сценариев, рекомендуется прописать для ваших решений их версии. Делается это в справочнике Приложения.
Внимание! Конфигурация выложена на базе версии 8.3.10, но работа ранних версий также поддерживается. Для этого, необходимо под версией 8.3.10 установить необходимый конфигурации режим совместимости, сохранить конфигурацию в файл и использовать его в качестве обновления.
За актуальными версиями следите здесь: https://github.com/grumagargler/tester
Отличный старт!
Посмотрим на выходных. Погода всё равно шепчет, так будет чем развлечься.
Нужная разработка. На выходных то же посмотрю….. 🙂
Подпишусь
Остался нераскрытым вопрос кто пишет тесты на тесты.
ибо если мы считаем что тесты пишутся правильно, то что нам мешает считать что правильно пишется программа?
(5) Тесты должны писаться так, что их правильность смогла бы понять даже бухгалтерша.
Например, для функции Добавить2К2() правильным тестом будет РезультатФункции = 4
(5) CheBurator, раскройте вопрос на практическом примере, так сложно ответить прицельно. Если вы имеете ввиду бизнес логику, то тестирование нужно для того, чтобы проверить ожидаемое поведение с фактическим, а вот насколько это ожидаемое поведение правильное — выходит за область тестера. Также, если во время тестирования возникает банальная ошибка обращения к несуществующему свойству или методу, уже само по себе не требует подтверждения правильности.
(8) CheBurator, пока в голову не приходят идеи, кто кроме человека может определить правильность тестов и их состав. Тестирование очень конкретная вещь и ожидать каких-то эвристических анализаторов всевозможных сценариев с их запуском и проверкой, не стоит, мы не решаем задачу коммивояжера. Есть сценарий – есть тест к нему. Сценарий не покрывает какие-то ситуации? Значит нужен еще один сценарий, который должен покрыть. Если таких сценариев много, начните с одного, это всё равно лучше, чем вообще ничего.
Интересно посмотреть очередную работу по тестированию.
Перед разработкой/при разработке изучали ли аналоги по тестированию в 1С ? Штатное сценарное тестирование от 1С, наш xUnitFor1C, еще vanessa-behavior, другие работы?
Было бы интересно увидеть справку в виде отдельного файла (markdown, html и т.п.), удобном для просмотра через браузер
Подписался
(10) artbear, да, конечно, эти разработки были изучены, именно поэтому родился тестер. Строго говоря, тестеру больше года, просто сейчас решил выложить его, потому что всё чаще стала подыматься тема простых инструментов тестирования. На счет справки, нужно подумать, всё-таки там не один документ, а два (справочники Сценарии и Приложения) и будет больше (под каждый объект метаданных)
(10) artbear, я перечитал своё сообщение, и решил дополнить, чтобы не показаться снобом. Тестер был создан не вопреки существующим программам, а по той причине, что он решает немного другие задачи и немного иначе. Я надеюсь, что дополнительный инструмент станет хорошим подспорьем для людей, интересующихся этим вопросом.
Заинтересовало, подпишусь
Спасибо, очень интересно!
Как мне протестировать такой сценарий — один пользователь открывает документ, начинает редактировать, другой пользователь вызывает программную обработку, обработка должна вызвать исключение, если документ редактируется?
А чем vanessa не устроила?
Там почти все можно мышкой накликать.
(16) Fragster, есть несколько возможностей, например, вы можете в коде теста выполнить действия первого пользователя, затем, отключиться от приложения (метод Отключить()), изменить параметры подключения через структуру AppData, затем, запуститьПриложение () с указанием другого порта (см. пример в справке), подключиться и продолжить выполнение сценария. Другой способ, запустить тестер из сценария, с указанием стартующего сценария, который сделает действия второго пользователя. Если у вас не получится — напишите, я попробую накидать код.
(17) JohnyDeath, (тут сложно ответить так, чтобы тебя не воспринимали в штыки, всё-таки ванесса продукт, которым пользуются многие, прошу воспринимать ответ только дополнение к общему делу) . Развернуто, я ответил здесь:https://habrahabr.ru/post/307808/
Если вкратце, кроме в разнице подходов, нам не удалось ванессой описать реальные сценарии, в приемлемые для нас сроки. Не получалось и прокликать без ошибок действий 25-30. В конце всех попыток (пробовали не только ванессу) всё свелось к тому, что нам нужен был механизм программного взаимодействия с тестируемым приложением, чтобы удовлетворить наши требования.
Отличная вещь, спасибо! У меня тестер очень непринужденно вписался в содружество хЮнит и Ванессы, обеспечив тестирование «без правил» и «по-быстрому» :). По публикации: она получилась больше для тех, кто уже тестирует, поэтому, как мне кажется, была бы полезной еще одна статья для тех, кто пока не совсем в теме: Ваш инструмент, пожалуй, имеет самый низкий порог вхождения на данный момент, и существенно ускоряет сам процесс разработки, а это делает его полезным даже для тех, кто пока не готов тратить время на имплементацию хДД. Для раскрытия этого момента, как мне кажется, нужно описание практического примера, типа добавляем в БП 3.0 основные единицы измерения, а потом ставим обновления, с описанием процесса и вытекающих выгод при последующей поддержке. У самого руки чешутся написать, но понимаю, что просто не смогу сделать это за разумное время. Еще раз хочу поблагодарить за удачный инструмент 🙂
(8) CheBurator, самый незатратный способ определять, какие тесты нужные — это хотя бы начать закрывать тестом каждую возникшую проблему. Оно конечно реактивно получается, но через некоторое время получается добротный, «правильный» набор тестов. А еще например Вы пишете отчет, время от времени запускаете его и смотрите, что получилось. Так вот если запускать не руками, а накидать запускатор, то и отладка пойдет веселей, и вот он — тест, а значит меньше мучаем бедных кладовщиков и других ни в чем не повинных животных. Лично я за максимально гуманное отношение к кладовщикам и животным 🙂
Все, прочитал статью на хабре — вопрос по отдельной статье для начинающих можно считать полностью раскрытым, спасибо.
(20) sorb, спасибо! да, я подумаю на счет небольшой статьи с практическими примерами, хотя конечно тема тестирования у многих ребят уже просто в печенках. И ситуация такая, что вроде все понимают, что надо, а вот когда пытаются — опа, а тут оказывается инвестиция времени нужна такая, что уже вроде не очень то уж и хотелось. Конечно, можно утверждать, что те, кто сдался, недостаточно твердые, чтобы идти до конца, или продавливать тему административно. Но ведь в тоже самое время, можно ведь и допустить, что проблемы и в инструментарии, который нам надо улучшать.
(10) artbear,документация (link из конфигурации).
(24) CSiER, к сожалению, в таком варианте не будет работать переход из оглавления по ссылкам, желательно справку открывать из тестера 🙂
а есть кнопка «создать тесты открытия всех форм»? и прочие подобные пакетные кнопки?
матрицу критериев успеха/отказа по ролям/пользователям также очень хочется — чтобы проставил галочками где тест должен сработать, а где — отвалиться, и всё.
ну и хочется тестов на проверку условного оформления, хотя здесь скорее платформенное ограничение сработает…
(26) В описанной автором концепции правильнее будет «вызвать все команды командного интерфейса конфигурации».
(26) Fragster, таких тестов в начальной базе нет, всё-таки тестер больше для сценарного тестирования, и тем не менее, их можно создать самостоятельно! если будет возможность, создавайте и выкладывайте на жит для других коллег 🙂
Интересная тема! Скачал базу, но при запуске ошибка:
Ошибка инициализации модуля: CommonModule.DF.Module
по причине:
{CommonModule.DF.Module(98,10)}: Процедура или функция с указанным именем уже определена (Pick)
Function <<?>>Pick ( val Ref, val Field, val Default = undefined ) export
платформа 8.3.9.1818 исправьте плз или как запускать правильно?
День добрый! Уточните пожалуйста, откуда вы скачали базу?
https://github.com/grumagargler/tester
Вот ссылка на актуальный релиз, способный работать под 8.3.9:
База, приложенная к теме, тестировалась на версиях <= 8.3.8
(32)Чего-то не работает под 8.3.9. 10-ю версию платформы хочет.
(33) скачайте пожалуйста с гитхаба последнюю версию, там эта проблема решена.
Для Бух 3.0 есть или планируются тесты ?
(35)
мне не приходится вплотную работать с этой конфигурацией, поэтому с моей стороны — ответ нет.
Возможно, другие коллеги уже имеют какие-то наработки, и поделятся, ведь технически всё для этого есть.
(34) скачал последнюю — 1.3.2.15 cf — обновлено 8 часов назад —
не могу даже режим совместимости выставить
(37)
у вас нет под рукой 8.3.10, или какая-то другая проблема?
(38)Нет под рукой 8.3.10. Думаю у большинства пока 8.3.9 — иначе не стал бы беспокоить
(39)https://github.com/grumagargler/tester/raw/master/1Cv8.3.9.dt
(40)Спасибо ! Все работает
приходите в специальный чатhttps://gitter.im/tester1c/Lobby , там вам другие коллеги смогут более оперативно помогать
(39) влезу: 8.3.10 по опыту работы с ней чудо как хороша, пожалуй самая стабильная и безбажная с момента появления 8.3. Перебирайтесь, не пожалеете 🙂
(20)
Наконец-то мне удалось завершить подготовку расширенной статьи, можете почитать здесь:http://infostart.ru/public/642946/
В чем ключевое отличие от 1С-овской?
(45) решение максимально приближено к разработчику, включая циклы перезапуска и покрытие пограничных/сложных случаев. Вытекающее другое отличие — в тестера сценарии программируются.
(45) а 1С-овская — это какая?