Автотесты для 1С: xUnitFor1C #765198

Используете ли вы эту систему в своей разработке? Система выглядит в целом приятно, я написал несколько простых тестов. Но все время натыкаюсь на сложности. Например не оч. понятно как выгружать тестовые данные (у меня на простом документе всё зависло) и как им удается избегать точки останова в отладчике. :-)

Ибо Длинных разработок с нуля нет Адля мелких допилов типовых конф нафиг не нужна

У нас длинная разработка с нуля. Поступило требование от руководства - тестировать. ? Думаю, что со временем такие требования станут общими, и даже 1С к ним подтянется. ?

Смайлы пропечатались как знак ?

Думаю что проще всего запустить тесты для процедур перед записью (проверки и заполнения), процедур проведения. Причем, только позитивные тесты (что документ в этих ситуациях не выдает исключений). Печать еще можно туда же подтянуть. Это минимум, который можно сделать не думая - получится проверка на соответствие реквизитов коду и на работоспособность запросов.

Так авторы все тут: , (этот в бане за укропство).

Сделал (для какой-то другой цели) разбор кода 1С (выделение строковых литералов и комментариев) через тестирование. Тест выполнен не через xUnitFor1C, но смысл - примерно тот же (?). Оказалось, что всякий разбор чего-либо через тестирование кодить гораздо приятнее.

Кому то захотелось продолжение банкета? Нужели еще не все не наговорились на эту тему?

Ага поставил теги, чтобы ветки не потерялись. ИМХО пора уже секцию заводить. :-)

Решили копать именно в направлении xUnitFor1C. Но там повсюду какие-то сложности (возможно, они все вызваны временным несовершенством движка 1С, а когда за тестирование возьмется (?) сама 1С, все они будут так или иначе решены). Например, получение списка функций и их исполнение так, чтобы оставался работоспособным отладчик 1С. Выгрузку и загрузку тестового набора я задумываюсь сделать не через Моксели, а своей разработкой, чтобы закачивало пошагово рекурсивно через веб или файлы+LCK.

Ага, добавил тегов.

Ничего странного в своей статье не находишь?

Просто небольшой пример, чтобы не потерялось. Зачем это нужно - на диске ИТС есть штатный тест кода на соответствие стандартам. Хочу под него кое-что у себя в 1С позатачивать, вдруг получится. Но он не выявляет даже ошибочных запросов (например, когда я преднамеренно вношу в код запроса ошибки). Так что для таких тестов понадобится что-то вроде xUnitFor1C.

Читаю старую ветку на запись документов по списку (ПередЗаписью, ОбработкаПроведения) - это, скорее всего, будет то, с чего окажется проще всего начать покрытие тестами (для начала - простыми позитивными) уже существующей написанной конфигурации. Записывается и проводится документ - хорошо, выдает исключение или не проводится - плохо.

Согласен с  artbear вот здесь: " Тесты ГУИ писать лучше пореже, слишком это неблагодарное и сложное дело. Лучше всю бизнес-логику выносить из ГУИ, чтобы слой бизнес-логики был изолирован от формы". Я у себя с формы документа массивные проверки ПередЗаписью поубирал в модуль менеджера. А там уже на форму можно не лезть, а просто тестировать на примерах документов.

Там же 318 - да, когда пишешь падающий тест сначала - это удобно. По крайней мере, для функций, которые должны что-то строковое кропотливо разбирать или парсить. Для типичных примеров разработки в 1С (таких как экзаменационные задачи) будет ли быстрее сначала создать тест? И как его создать: руками, что ли, вносить. И куда. Вот этот вопрос я пока не могу понять в xUnitFor1C, там есть какие-то таблицы, но с какой стороны к ним подойти - сходу непонятно.

чтото я в тестах не увидел теста на обработку

Добавил тест №13.

добавить - не вопрос! Вопрос - почему его не было? И мне кстати интересно Пройдет ли тест Стр = "|" ???

Наверняка можно еще придумать несколько тестов - будет движение к совершенству. :-)

вопрос в том, что и предыдущиая моя строка и эта - это явные граничные условмя, проверять их надо однознвчно, странно что этого нет в тестах

Тест 2. Комментарий там в любом случае не пустой, возвращает минимум // если он есть. Поэтому это не граничное условие. Но почему бы его не ввести - я только за. Лучше перебдеть, чем недобдеть.

"возвращает минимум // если он есть" - это ваше мнение, не подкрепленное тестом. я бы включил в тесты проверку обработки как минимум следующих строк Стр="""|"""; - это навскидку, не думая

Не в этом был вопрос. Посчитай количество строк кода, непосредственно решающих задачу, и количество строк в тестах. Заметь, что тесты не покрыли и половины случаев.

Все случаи имхо отработаны. Там можно и ( | ) разными способами нарисовать - кому как больше нравится. Кстати, это вики - желающие, если пример заинтересовал, могут вносить улучшения. Там же, как говорят, рулит парное программирование, просмотр чужого кода, и все такие дела. :-) Ответственных или вертикали тут нет - интернет - это одна сплошная безответственность. :-) Тесты не гарантируют отсутствия ошибок, а только уменьшают их вероятность (по кр. мере об этом, емнип, неоднократно пейсали artbear сотоварищи). Так или иначе - правьте смело.

а можно pumbaEO разбанить в 1с и забанить в лайф?

А он еще сидит на 1С? А как же принципы?

имхо - нет.. //// - весьма разные вещи, имхо

и ваще непонятно. нахрена эта тдд? если мне для верификации, нужно прогнать тест и сравнить это с эталонным результатом - который я откуда возьму? из головы? если у меня есть эталонный результат в голове - нафига мне строить тесты. которые будут мой эталонный результат из башки переносить в код. я это ВООБЩЕМ могу и без тестов сделать. не совсем тупой еще. для чего это тдд тогда? - просто некая методика, облегчающая воспроизведение моего представленяи результата в голове и его преобразования в код? тогджа такая методика д.б. достаточно формальной, чтобы ей можно было следовать "промышленным" способом. а по факту - мы имеем придумывание кода (нетривиальная операция) и придумывание тестов (та же самая нетривиальная операция) - где здесь формальность? я вон с ромиксом не могу согласиться насчет набора тестов даже в той задаче которую он нарисовал. Он считает - что тех тестов которые есть - достаточно, я - недостаточно. Вопрос: кто прав? где ИНСТРУМЕНТ? если один считает, что молотком 100 граммов забили легко гвоздик семерочку, и гвоздик десяточку - следует ли из этого что молотком 100 граммов будет также легко забить гвоздь двухсотку - кованный, четырехуголный..?

- а ну поподробнее прод дымовое тестирование. Это ТОЛЬКО проверка, запислася ли документ?

что такое тдд? - дисциплина программирования? если человек пишет изначально такой код, что я на него смотрю и мне то ли плакать, то ли смеяться хочется (мой код тогда ваще=принцесса) - с тдд он будет писать красивый код? очень сомневаюсь. будет все также криво, если даже не хуже...

- подброшу на вентилятор: это для прогеров, которые страдают ретроградной амнезией, постоянно отвлекаются на мисту и прносайты, а также не могут сконцентрироваться. Им, согласно мантре Fail First нужно сначала написать, что я хочу накодить, а потом тебе continous тест раннер скажет куда в коде нужно что-то вставлять.

И еще ТДД применяют для неуверенных в себе задроты. Настоящие Чаки Норрисы уверены, что только что внесенное изменение не повлияло на другие части кода. И комитят все в продакшн.

А причем тут внесения изменения и разработка программы?

у нас еще нет ничего, чистый лист, о каких изменениях написанных другим программистом идёт речь?

- читай, зачем нужен ТДД

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

Чаки Норрисы никуда не коммитят, а правят прямо на продакшене.

Да не будет нихера такой уверенности. Точнее, эта уверенность ложная. То, что CI собрал твой код и прогнал тесты не говорит о том, что он не содержит ошибок.

- ога. На площадке клиента. И клиент за это платит. Концепт: "клиент платит за ошибки программиста" - это я уже где-то слышал. Я не знаю, как там с 1С, но в JS тесты очень сильно все упрощают, особенно, если оно так делается:

Клиент платит за результат. А вот адептам xDD, похоже, платят за количество строк.

не, с нуля писать - может и полезно будет. но писать, не зная что писать... пока я упорно всю эту разработку через тдд свожу к разработке сверху вниз.

- >А вот адептам xDD, похоже, платят за количество строк. ты так говоришь, как будто это плохо

вообще TDD - это часть номрального СКРАМа в СКРАМе нет четких требований

еще ТДД очень сильно упрощает коммуникацию среди программистов. Особенно в интернациональных тимах.

кстати хорошая система оплаты. Только за уменьшение количества строк

- а почему оплата какаято не такая как договаривались? - ну потому что написали вы не то что нам хотелось...

Долой оплату за процес! Даешь оплату за результат!

1С как скриптовый язык не требует тестирования кода. Важнее тестировать сам бизнес-процесс.

бывает что по xDD РЕЗУЛЬТАТ получается быстрее, качественне и дешевле так что it depends

Сделай себе татуировку на лбу: "Никому не нужны программы, всем нужны результаты их работы."

- программистам платят за процесс, а не за результат

Прекрасный пример на видео с JS. См. с 0:50 по 1:02, когда в тесте пишется сначала: expect(calculator.multiply(3,4)).toBe; И всё - правильный (простейший!) код тест уже не пройдёт.

За процесс платят проституткам. Ну, может еще актёрам и певцам.

- программист никогда не может отвечать за результат. По определению.

программист может отвечать за то что при правильных данных программа работает верно или это будет оперативно исправлено программистом, с нахождением ошибок в исходных данных (пользователи накосячили) отвечает понятно дело руководитель и пользователь

За результат своей работы должен отвечать - или это херовый программист.

Если есть бюджет на написание тестов - нужно писать. А на нет и суда нет

- эх.. ты не работал программистом.

>не оч. понятно как выгружать тестовые данные (у меня на простом документе всё зависло) и как им удается избегать точки останова в отладчике. :-) Расшифруй оба пункта. что делаешь, что хочешь, что не так? Приглашаю в чат xUnitFor1C для более оперативных ответов от меня и других контрибьюторов

По дымовым тестам - в xUnitFor1C есть несколько примеров дымовых тестов. Например, я в свое время реализовал дымовой тест открытия всех форм (формы списков и элементов, справочники, документы, отчеты, обработки). Также делаются попытки перезаписи справочника и документа, создать новый элемент/документ Тест очень полезен при обновлении конфигурации. Также есть примеры запуска разных тестов под разными пользователям. удобно для проверки работы системы для разных ролей. и т.п. и т.д

Ага спасибо. Рабочая база слишком велика для тестирования, хочется закачивать отдельные документы между одинаковыми конфигурациями как раз для целей тестирования. Я полез в приложенную обработку xddDataFixtureGen, , интуитивно понажимал там на кнопочки, всё зависло (наверное, оказалась велика глубина рекурсии). Предположим мне удалось выгрузить Моксель, а дальше с ним что делать - руками парсить? Обратной обработки для загрузки я не нашел. Может там планируется закачиватель данных - или все на практике используют что-то готовое с ИТС/Инфостарта?

Эх, вот если бы кто замутил проект по написанию автотестов для типовых конфиг ....

есть процедура по созданию из мокселя

А доку хоть немного почитать? :) Смотрим вводную страницу Вики проекта Там написано: Возможно очень простое создание тестовых данных на основании табличных макетов. Эти макеты можно генерировать из реальных боевых данных. Полученные данные в тестах загружаются одной строкой кода. Посмотрите Генерация данных. Открываем Генерация данных Читаем и вставляем в свой код

Там же есть доп.ссылка на

Пример кода для v4 Пример кода для v3

[ковыряя MonoDevelop] Доктор, скажите, вот в MonoDevelop есть проблемы с отладчиком - там брейкпойнты не работают. И отладочная печать в консоль не выводится. Остается только выводить MessageBox-ом. Так вот, каковы преимущества MessageBox-Driven-Development по сравнению с Test-Driven-Development? Нужно ли мне статические блобы рефакторить в IoC  и потом писать юнит тесты? Спасибо за внимание, доктор.

А, спасибо. Всё еще хочу приделать закачиватель через Web-интерфейс, но попробую и так. Насчет работы отладчика - я кажется придумал как ее реализовать, даже не теряя совместимости. Дело в том, что если мы запускаем несколько десятков функций, которые что-то тестируют, при ошибке хочется видеть точное место ошибки и дерево вызовов, если ошибка произошла где-то внутри - то есть, именно то, что мы видим при обычном тестировании и отладке руками. В тестовой обработке нужно заготовить экспортируемые функции Тест_001, Тест_002, ... Тест_100 (наверное, 100 будет достаточно). Думаю, что это также уменьшит клавиатурный процесс и объем копи-паста при создании большого числа тестовых функций. Также экспортировать функцию с максимальным номером, например ЧислоПронумерованныхТестов - возвращает 45, если было задействовано 45 пронумерованных функций-тестов. Или выяснять максимальное число задействованных функций вызовом их с конца от 100 - первая, которая возвращает не Неопределенно - есть искомая. Можно сделать и так, и так, если сама функция ЧислоПронумерованныхФункций возвращает Неопределенно.

нафига он тебе такой? Тем более со скоростью работы 1С... Вынеси во внешнюю компоненту - будет счастье.

+ для теста такой случай еще а0 = "аааа

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

минимальный набор тестов - это 1 тест )))

Используем, хоть и не на всю катушку. Помогает даже не столько тестировать, сколько изначально грамотнее структурировать код.

хотя и регрессию пару раз отловили тестами.

Кто имеет с ними какие либо контакты, или где можно сообщить им об ошибке без регистраций каких либо. СериализаторMXL При загрузке макета созданного в БП2 из документа "РеализацияТоваровУслуг" с выгрузкой движений по регистру Бухгалтерии получаем ошибку: {ВнешняяОбработка.СериализаторMXL.МодульОбъекта(1077)}: ОшибкаПоиска:  Реквизит <СубконтоКт2>: Искали значение <НДС18> {ВнешняяОбработка.СериализаторMXL.МодульОбъекта}: Поле объекта не обнаружено (СубконтоКт2) Если потребуется, напишу как исправить/обойти.

Написал разработчику на почту

Можно создать задачу для исправления Предлагаю там же обсудить исправление. Спасибо за письмо.

Там регистрация требуется. Мне пока как-то без надобности.

Лады, пиши сюда. Жду

Общий смысл ошибки заключается в том, что значение этого субконто в проводке есть перечисление. При генерации макета колонка доп.тип в этом случае не заполняется. В коде, который загружает макет, этот реквизит в "попытке" не находит описание метаданных и валится с описанной ошибкой. Я это у себя поправил. Дальше можно руками в макете дописать "ПеречислениеСсылка.<КонкретноеИмя>". Ну и можно при генерации макета сделать то же самое.

В терминах кода это выглядит так: строка модуля объекта № 994 МетаданныеРеквизита = НаборМдРеквизитов[стрПоле.Имя];

и в функции Функция ОбработатьРеквизитОбъекта( после строк:         ВызватьИсключение описаниеОшибки + " Не умею обрабатывать реквизит <"+имяРеквизита+"> у объекта <"+Мд.ПолноеИмя+">"; строка

Возможно это и не лучшая правка, если я не совсем понял алгоритм автора.

1 Можешь свой доработанный вариант обработки генератора скинуть мне на мыло? aartbear(гав)gmail 2 Достаточно доработки в обработке-генераторе? обработку-тестирования xddTestRunner не нужно дорабатывать для правильного получения данных из макета?

+ вопрос 2 снимается, т.к. ты используешь версию с плагинами и изменение нужно сделать только в одном модуле.

Отправил.

Не прошло, у тебя на самом деле в начале 2 буквы аа?

Ушло.