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

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

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

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

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

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

Сделал (для какой-то другой цели) разбор кода 1С (выделение строковых литералов и комментариев) через тестирование.
http://wiki.mista.ru/doku.php?id=1c:v8:razbor_koda_1s
Тест выполнен не через xUnitFor1C, но смысл - примерно тот же (?).
Оказалось, что всякий разбор чего-либо через тестирование кодить гораздо приятнее.

Кому то захотелось продолжение банкета?
А ты правильно разрабатываешь на 1С?
TDD (Разработка через тестирование)

Нужели еще не все не наговорились на эту тему?

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

(7) Решили копать именно в направлении xUnitFor1C.

Но там повсюду какие-то сложности (возможно, они все вызваны временным несовершенством движка 1С, а когда за тестирование возьмется (?) сама 1С, все они будут так или иначе решены).

Например, получение списка функций и их исполнение так, чтобы оставался работоспособным отладчик 1С.

Выгрузку и загрузку тестового набора я задумываюсь сделать не через Моксели, а своей разработкой, чтобы закачивало пошагово рекурсивно через веб или файлы+LCK.

v8: v8: Разработка через тестирование и просто автоматическое тестирование. Кто практикует?
Разработка через тестирование - мракобесие и профанация...?

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

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

(12) Просто небольшой пример, чтобы не потерялось.

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

Но он не выявляет даже ошибочных запросов (например, когда я преднамеренно вношу в код запроса ошибки). Так что для таких тестов понадобится что-то вроде xUnitFor1C.

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

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

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

(6)  чтото я в тестах не увидел теста на обработку
Стр = "//";
Почему?

(17) Добавил тест №13.
http://wiki.mista.ru/doku.php?id=1c:v8:razbor_koda_1s

(18)  добавить - не вопрос!
Вопрос - почему его не было?

И мне кстати интересно
Пройдет ли тест
Стр = "|"

???

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

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

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

(22) "возвращает минимум // если он есть" - это ваше мнение, не подкрепленное тестом.

Чистый комментарий "//" - именно без текстовки - как раз вполне граничное условие, ибо неоднократно в тексте встречается обработки.

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

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

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

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

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

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

(25) имхо - нет..
тестировать прохождение
//ааа
и
//
и
////
- весьма разные вещи, имхо

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

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

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

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

(29) - подброшу на вентилятор:

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

Им, согласно мантре Fail First нужно сначала написать, что я хочу накодить, а потом тебе continous тест раннер скажет куда в коде нужно что-то вставлять.

И еще ТДД применяют для неуверенных в себе задроты.

Настоящие Чаки Норрисы уверены, что только что внесенное изменение не повлияло на другие части кода.

И комитят все в продакшн.

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

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

(34) - https://ru.wikipedia.org/wiki/Разработка_через_тестирование

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

(34) - когда ты разрабатываешь программу, ты вносишь последовательные изменения.

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

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

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

(38) - ога. На площадке клиента. И клиент за это платит.

Концепт: "клиент платит за ошибки программиста"

(39) - это я уже где-то слышал.

Я не знаю, как там с 1С, но в JS тесты очень сильно все упрощают, особенно, если оно так делается:

http://www.youtube.com/watch?v=xng_ymsnJks

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

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

(41) -

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

ты так говоришь, как будто это плохо

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

в СКРАМе нет четких требований

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

Особенно в интернациональных тимах.

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

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

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

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

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

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

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

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

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

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

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

отвечает понятно дело руководитель и пользователь

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

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

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

(0) >не оч. понятно как выгружать тестовые данные (у меня на простом документе всё зависло) и как им удается избегать точки останова в отладчике. :-)

Расшифруй оба пункта.
что делаешь, что хочешь, что не так?
Приглашаю в чат xUnitFor1C для более оперативных ответов от меня и других контрибьюторов https://gitter.im/xDrivenDevelopment/xUnitFor1C?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge

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

(60)(61) Ага спасибо. Рабочая база слишком велика для тестирования, хочется закачивать отдельные документы между одинаковыми конфигурациями как раз для целей тестирования.
Я полез в приложенную обработку xddDataFixtureGen, включил затупитель, интуитивно понажимал там на кнопочки, всё зависло (наверное, оказалась велика глубина рекурсии).

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

Может там планируется закачиватель данных - или все на практике используют что-то готовое с ИТС/Инфостарта?

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

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

(62) А доку хоть немного почитать? :)
Смотрим вводную страницу Вики проекта https://github.com/xDrivenDevelopment/xUnitFor1C/wiki

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

Открываем Генерация данных
https://github.com/xDrivenDevelopment/xUnitFor1C/wiki/Генерация-данных

Читаем и вставляем в свой код

Там же есть доп.ссылка на https://github.com/xDrivenDevelopment/xUnitFor1C/wiki/Генерация-макета-на-базе-реальных-данных

Пример кода для v4
Процедура ТестДолжен_СоздатьПростойСправочник() Экспорт
    Макет = ПолучитьМакет("СозданиеПростогоСправочника");
    ТестовыеДанные = СериализаторMXL.СоздатьДанныеПоТабличномуДокументу(Макет);

    ПроверитьСозданиеПростогоСправочника(ТестовыеДанные);
КонецПроцедуры

Пример кода для v3
Процедура Тест_ДолженСоздатьПростойСправочник() Экспорт
    Макет = ПолучитьМакет("СозданиеПростогоСправочника");
    ТестовыеДанные = ЮТест.СоздатьДанныеПоТабличномуДокументу(Макет);
    
    ПроверитьСозданиеПростогоСправочника(ТестовыеДанные);
КонецПроцедуры

[ковыряя MonoDevelop] Доктор, скажите, вот в MonoDevelop есть проблемы с отладчиком - там брейкпойнты не работают.

И отладочная печать в консоль не выводится.

Остается только выводить MessageBox-ом.

Так вот, каковы преимущества MessageBox-Driven-Development по сравнению с Test-Driven-Development?

Нужно ли мне статические блобы рефакторить в IoC  и потом писать юнит тесты?

Спасибо за внимание, доктор.

(65) А, спасибо. Всё еще хочу приделать закачиватель через Web-интерфейс, но попробую и так.

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

В тестовой обработке нужно заготовить экспортируемые функции Тест_001, Тест_002, ... Тест_100 (наверное, 100 будет достаточно).

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

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

Или выяснять максимальное число задействованных функций вызовом их с конца от 100 - первая, которая возвращает не Неопределенно - есть искомая. Можно сделать и так, и так, если сама функция ЧислоПронумерованныхФункций() возвращает Неопределенно.

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

+ для теста такой случай еще
а0 = "аааа
|ббб
//|ввв"
|ггг"

а1 = "аааа
|ббб
//ввв"
|ггг"

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

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

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

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

Кто имеет с ними какие либо контакты, или где можно сообщить им об ошибке без регистраций каких либо.
Ошибка в плагине
СериализаторMXL

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



Если потребуется, напишу как исправить/обойти.

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

(76) Можно создать задачу для исправления https://github.com/xDrivenDevelopment/xUnitFor1C/issues/new

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

(77) Спасибо за письмо.

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

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

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

В терминах кода это выглядит так:
строка модуля объекта № 994
МетаданныеРеквизита = НаборМдРеквизитов[стрПоле.Имя];
заменена на
            ////*//{СТ===== № 00004 ======== 18.02.2016 16:50:54
            //МетаданныеРеквизита = НаборМдРеквизитов[стрПоле.Имя];
            //---- Заменено на: ----
            ИмяС = Лев(стрПоле.Имя,10);
            ДопТ = ВРЕГ(Лев(стрПоле.ДополнительныйТип,19));
            Если Режим = "ПРЕДОПРЕДЕЛЕННЫЙ" И ДопТ = "ПЕРЕЧИСЛЕНИЕССЫЛКА." И (ИмяС="СубконтоДт" или ИмяС="СубконтоКт")Тогда
            Иначе
                МетаданныеРеквизита = НаборМдРеквизитов[стрПоле.Имя];
            КонецЕсли;
            ///////}СТ===== № 00004 ======== 18.02.2016 16:50:54

и в функции Функция ОбработатьРеквизитОбъекта(
после строк:
        ВызватьИсключение описаниеОшибки + " Не умею обрабатывать реквизит <"+имяРеквизита+"> у объекта <"+Мд.ПолноеИмя()+">";
    КонецПопытки;
строка
Если ЕстьТипы И РеквизитМд.Тип.Типы().Количество() = 1 Тогда
заменена на
    ////*//{СТ===== № 00004 ======== 19.02.2016 14:22:41
    //Если ЕстьТипы И РеквизитМд.Тип.Типы().Количество() = 1 Тогда
    //---- Заменено на: ----
    Если ЕстьТипы И РеквизитМд.Тип.Типы().Количество() = 1 И Лев(ДополнительныйТипЗначения,19) <> "ПеречислениеСсылка." Тогда
    ///////}СТ===== № 00004 ======== 19.02.2016 14:22:41

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

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

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

Отправил.

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

Ушло.