TDD (Test Driven Development, то есть "разработка через тестирование"). Очень популярная в тру-программировании концепция, позволяющая серьёзно повысить производительность труда программистов. В 1с инструментов для этого пока что нет, но тут виной скорее концептуальные особенности 1с. Если в той же Java есть возможность протестировать отдельный класс сам по себе, то в 1с так не сделаешь, за редким исключением (например, несложные экспортные методы общих модулей).
Да, есть такие штуки, как xUnitFor1C, Vanessa-behavoir и иже с ними. Но это скорее BDD, которое хоть и принято считать ответвлением TDD, но по сути таковым не является.

Суть TDD: модульные тесты должны писаться заранее, еще до написания кода продукта (разработка ЧЕРЕЗ тестирование). Т.е. кода (метода, например) ещё нет, а тест под будущий код уже есть. Р.Мартин выделяет три закона TDD:
"Первый закон. Не пишите код продукта, пока не напишете отказной модульный тест.
Второй закон. Не пишите модульный тест в объеме большем, чем необходимо для отказа. Невозможность компиляции является отказом.
Третий закон. Не пишите код продукта в объем большем, чем необходимо для прохождения текущего отказного теста.
Эти три закона устанавливают рамки рабочего цикла, длительность которого составляет, вероятно, около 30 секунд. Тесты и код продукта пишутся вместе, а тесты на несколько секунд опережают код продукта. При такой организации работы мы пишем десятки тестов ежедневно, сотни тестов ежемесячно, тысячи тестов ежегодно. При такой организации работы тесты охватывают практически все аспекты кода продукта" (с)

По-моему уже понятно, что все эти ванессы-шманессы ни разу не TDD, и TDD как такового в 1с нет. xUnitFor1C ещё как-то что-то похожее, но полноценным TDD там и не пахнет. Кто что думает, появятся ли для 1с удобные утилиты, позволяющие полноценно разрабатывать с применением TDD?

30 секунд - это что имеется в виду и что за 30 секунд можно написать? Я вот эту фразу примерно столько пишу, может, чуть меньше.

(1) это по-мартиновски 30 секунд. Роберт Мартин призывает писать коротенькие методы (на Java по крайней мере), чтобы один метод составлял 2-6 строк. Маленькие компактненькие методы. Наверно поэтому такой короткий интервал времени он берёт. Маленький тестик метода, маленький метод, маленький тестик метода, маленький метод... Но это моё предположение. Может просто неточность/ошибочность перевода, и на самом деле там не секунды, а минуты

Маленькие компактненькие...
Где-то это я уже видел... А, точно. В БСП. С вложенностью стека на 60-70

(0) Когда будет значительное число проектов "с нуля", а не перепилки типовых - тогда может это будет иметь смысл. А так - ну чисто 1С-никам почувствовать себя настоящими программистами :))

А не, перевод нормальный. В оригинале
These three laws lock you into a cycle that is perhaps thirty seconds long. The tests and the production code are written together, with the tests just a few seconds ahead of the production code

(3) а чем тебе вложенность стека не угодила?

(4) TDD не делит разработки на маленькие и большие, с нуля и не с нуля. Под TDD можно разрабатывать хоть 100 строк кода с нуля, хоть 100.000 строк кода для существующей системы

(6) Я комплексую, когда у 1с длиннее, чем у меня )))

(8) сделай у себя длиннее)

(0) а чем тогда пользователи на продакшне будут заниматься вместо тестирования?

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

(2),(5) а там примеров нет? Идеализм какой-то. Против коротких методов я ничего не имею, но.
Во-первых, есть разделение алгоритма на отдельные блоки. Если я выношу логический блок в метод и у меня получается минимум 8-10 строк, а не 6 - это я дурак? Или все же нет?
Во-вторых, даже пять строк можно тестировать и отлаживать больше 30 секунд.
Что-то здесь не то.

(7) Ну так на код от 1С нет покрытия, а за то, чтобы было, никто платить не будет.

TDD – это порочный подход. Уже много раз обсуждено, не хочу повторяться.

(0) > Очень популярная в тру-программировании концепция, позволяющая серьёзно повысить производительность труда программистов.

Тут как раз наоборот, производительность снижается, но повышается стабильность кода.
Кто тебе речь писал? :) Филолог? :)

(0) Для TDD нужна хорошая модульность. В частности, возможность создания моков для любых объектов, в т.ч встроенных. Не думаю, что 1С будет прилагать большие усилия в этом направлении. Это не выгодно фирме 1С. Почему? Сейчас платформа 1С это монолит, который если ты решил использовать, то нужно использовать по-полной. Или не использовать совсем. Все компоненты платформы, такие как объекты метаданных (ORM), средства разработки форм (GUI toolkit), средства разработки отчетов (СКД) и т.д. неразрывно связаны между собой. Ты не можешь, к примеру, взять стороннюю библиотеку для доступа к данным и привязать ее объекты к элементам на форме, или использовать сторонний менеджер блокировок вместо встроенного. Или хранить документы и справочники в какой-нибудь NoSQL базе данных. Это классический бандлинг (https://en.wikipedia.org/wiki/Product_bundling#Software)

Не секрет, что у 1С не Google и не Microsoft, у нее недостаточно ресурсов, чтобы сделать все компоненты платформы лучшими в своем классе или хотя бы не уровне лучших. Это компенсируется бандлингом.

Если улучшить модульность платформы, появятся возможности для анбандлинга, то есть разборки платформы. Разборка снизит конкурентные преимущества отдельных частей. Попытки анбандлинга и сейчас предпринимаются (metadata.js и прочие), и думаю, 1С наблюдает за ними с большой тревогой.

По той же причине я не ожидаю развития языка 1С в сторону улучшения ООП.

(12) там много примеров. В двух словах не описать. Если интересно, прочти книгу (есть в электронном варианте):
ozon.ru/context/detail/id/5011068/

ИМХО 1С-у TDD нужен в редких случаях.
Это же не файловая система или менеджер памяти.
Тут многое проще.

(14) например?

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

+(19) критикую всё. Критикуют ООП, критикуют windows, критикуют 1с. Нопочему-то они остаются очень популярными, а часто и самыми эффективными. Хотелось бы убедится, что хоронители TDD это не типичные критиканы, главная цель которых покритиковать

(21) Ну как бы сколько лет TDD, лет 20? А оа почему то выстрелила не так сильно

(21) ну, сигареты и прочая наркота тоже популярны.
не стоит мерить правильность популярностью :)

(20) сложность тестирования проведения документов скорее упирается в концепции платформы 1с. Да всё TDD упирается в это. Процедура Хуяк(), а за ней алгоритм на 10 тыщ строк кода в модуле менеджера, и единственный способ постучатся к этому коду процедура Хуяк(), до отдельных участков алгоритма не достучаться. Есть, конечно, способы как это обойти, но это всё из разряда дрочерства: делать многие процедуры экспортными, например.

(23) ничего общего с сигаретами у методик работы нет. TDD используют чтобы повысить производительность своего труда, качество продукта, а не из-за наркотической зависимости) Если бы TDD был неэффективным, он не был бы популярным

(24) И не только. Время разработки вырастает процентов на 25%, при этом количество ошибок уменьшается где то на 40%. При условии что нужно было еще вчера выпустить релиз, то невыгодно

(25) каким местом "TDD используют чтобы повысить производительность своего труда" - что за бред?

(0) Нахрена тебе в 1С TDD? И как ты это себе представляешь?

ОФФ: Автору стоит устроиться на работу в 1С. У него еще много задумок осталось. ))

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

(30) какое отношение автоматизированное тестирование имеет к TDD?

(31) кхм... Стесняюсь спросить, а что такое по-твоему TDD?

TDD — это тупиковый путь
Написал миллион тестов, отдал разработчику, тот сделал какого-то отвратительного франкенштейна, но по тестам все тютелька в тютельку, ни одной ошибки

TDD на примере разработки калькулятора
Сделали тесты, что 5 + 5 = 10, 5 - 5 = 0, 5 * 5 = 25, 5 / 5 = 1
Отдали разработчику
Тот сделал калькулятор, который верно вычисляет выражения 5 + 5, 5 - 5, 5 * 5 и 5 / 5, то есть тесты полностью проходят
А вот если попробовать на нем посчитать 2 + 2, то будет не 4, а, например, 10
Почему?
Ну тут же плюс в выражении, как и в 5 + 5, значит должно быть 10
А 5 + 3 - 2 вообще будет равно нулю, потому что такое описано в тестах не было и хрен его знает, как здесь считать

И кто после этого дебил?

(31) Да вроде как непосредственное
А вы с какой целью интересуетесь? :))

(33) TDD так не применяют. При TDD разработчик сам пишет тесты для своего же кода. В твоём примере вопрос адекватности тестов (или покрытия тестами), а не в методике тестирования. На такой косяк можно наткнуться при любой другой методике тестирования, если покрытие кода будет недостаточным

(34) Тут 2 сценария.
1. Пишем код программы, вручную проводим какие-нибудь тесты и лишь затем пишем автоматизированные тесты для имитации различных ситуаций. Имея надлежащие тесты можно свободно переходить к следующей фиче или провести рефакторинг, не боясь что-нибудь сломать. Мне кажется что это явно не TDD

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

(35) И как это ускоряет разработку?

(35) Практика показывает, что программист пишет те тесты, которые, как правило, не имеют никакого отношения к реальной деятельности пользователей
Зато те тесты, которые нужно писать, программист не пишет
В итоге получается много, дорого и богато, зато бесполезно

(35) На такой косяк при BDD ты не наткнешься а принципе, потому что разработчик пишет код не отталкиваясь от тестов, а отталкиваясь от поставленной задачи

Уверен, что в 1С TDD дальше отладки и Сообщить() не пойдет

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

(0) Не будет, конечно. "Настоящее" TDD с идеями типа давайте напишем тест на вызов несуществующего метода не применимо ни где, кроме smalltalk'а для которого его и придумали.

>Сначала сесть подумать, потом писать код, а не как обычно сначала пишут код
Это не так.
Идея "настоящего" TDD в том чтобы сначала также "бездумно" (как обычно код) писать тесты.
А сначала сесть и подумать - это водопад и вообще ретроградство.

(42) А что, в скраме думать не надо? O_o

(42) Ты не сможешь бездумно написать код, если даже не понимаешь что тестировать и какие у тебя данные на входе и выходе. Т.е. хотя бы в общих чертах представляешь весь процесс. И тут как раз и будет первая засада. Потому что ленивые жопы пишут тест исходя из нормально работающей системой с предсказуемыми множествами данных (пример в (33))

(37) количество ошибок, доделок-переделок существенно уменьшается, например. К тому же, TDD неплохо дисциплинирует. Ты следишь за тем, чтобы API твоих алгоритмов был как можно компактнее. Без тестирования кода херакнул процедуру, получающую в параметрах структуру с 50 ключами, и пошел дальше. Но когда ты сразу разрабатываешь тест кода, так писать код уже не будешь. Чтобы тест не превратился в зловещий ребус, тебе нужно сделать процедуру такой, чтобы на входе она получала как можно меньше легкоконтролируемых параметров. Это очень важно. Такой код намного гибче, в будущем его будет легче дорабатывать, что уже является повышением производительности

"Но когда ты сразу разрабатываешь тест кода, так писать код уже не будешь" - почему?
Ну будет вместо 50 параметра 1 параметр с типом структуры в котором я могу безболезненно запихнуть еще 100500 параметров и тесты не будут на это реагировать, так как они ничего о них не знают. А так в случае добавления 51 параметрах у меня тесты сразу провалятся, так как не совпадает количество параметров

(45) Да всем посрать, сколько у тебя параметров в процедуре
Люди напишут BDD, который прогонит цикл ключевых операций, твой говнокод свалится и, ты не поверишь, кому на голову упадет все то дерьмо, которое ты подкинул в воздух
Так что программисты с IQ выше 40 пишут сразу читабельный максимально простой код не потому что так проще, а потому что делают это ради самих себя же

(38) это уже вопрос квалификации программиста, а не тестирования как такового

И чем проще писать код если структура, а не отдельный параметр?

(48) И мы приходим к еще одной глобальнгой проблеме TDD - отсутствия культуры тестирования. Зачастую даже не понятно что и зачем тестировать

(48) Что за бред?
Еще раз
TDD — это когда сначала написали в тестах, как должно работать, и потом прогер делает так, чтобы работали тесты
BDD — это когда сначала прогеру говорят человеческим языком, как должно работать, и потом прогер делает так, чтобы работали тесты
В первом случае при разработке прогер _уже_ знает тесты, во-втором случае узнает их только после того, как его говнокод где-то начнет валиться
И, что важно, во-втором случае тесты наращиваются по мере появления новых ошибок

(46) чтобы тестирование было удобным и надежным, сигнатура метода должна быть минимальной. Например

Функция СледующийРабочийДень(Дата)

такую функцию тестировать легко. Подал на вход несколько дат, и проверил что функция возвращает

Процедура РассчитатьНекуюХрень(Парам1,Парам2,Парам3,Парам4,Парам5,Парам6,Парам7,Парам8,Парам9,Парам10)

такую процедуру протестировать очень сложно. Тест получится просто зашкварный. Представляешь сколько вариаций вызова такой процедуры потребуется? Когда ты заранее знаешь, что тебе нужно будет писать тест для этого кода, ты не будешь городить такую сложноту

(49) это не вопрос 10 параметров в методе, или одного параметра типа структура с 10 ключами. Это вопрос реорганизации кода так, чтобы он принимал 2 параметра простого типа

(52) мы точно говорим о случаях сложнее чем Привет, Мир!?
Любая бизнес логика подразумевает кучу параметров

(52) А зачем мне как пользователю тестировать результат функции РассчитатьНекуюХрень?
Что это за функция?
Вызывается ли она где-нибудь хоть раз?
Что такое функция вообще?
Что полезного мне даст информация о том, работает эта функция правильно или нет?
Нахрена мне все это?

Хорошо как написать функцию получения цены товара в УТ11 используя 1 параметр

а главное какой тест мне написать, чтобы проверить что функция возвращает правильное значение?

(51) чувак, TDD это совсем не про то. При TDD тесты пишет сам программист, а не сторонний Вася.

Нужно мне написать функцию СледующийРабочийДень. Первым делом я пишу тесты, которые проверят эту функцию:

СледующийРабочийДень(03.10.2020) = 05.10.2020
СледующийРабочийДень(20.10.2020) = 21.10.2020
СледующийРабочийДень(31.12.2020) = 11.01.2021

и только после этого приступаю к реализации самой функции СледующийРабочийДень()

(55) Давайте спорить о вкусе устриц с теми, кто их ел. (с) М. Жванецкий

(58) Рукалицо
Вернись назад, прочитай ветку с начала, а то по второму кругу пошли

Про
СледующийРабочийДень(03.10.2020) = 05.10.2020
СледующийРабочийДень(20.10.2020) = 21.10.2020
СледующийРабочийДень(31.12.2020) = 11.01.2021
молчу, странные тесты

Не будет. Язык вообще не позволяет писать юнит тесты.

(59) Эээ... ну давайте
Я ел
Ты ел?

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

(60) как по-твоему тесты кода выглядят? Именно так код и тестируется. На вход определённые параметры, на выходе проверяется, соответствует ли результат ожидаемому

(61) это да. Языковое ограничение существенное

(64) А, ты же про рабочие дни, ну ok

Тестирования не хватает конечно. У нас очень сложный механизм скидок с большим количеством вариантов. Билеты бонусы акции, сезонные скидки, скидки по волшебному слову, ну и тд. Каждый раз прикручиваешь новый механизм, думаю не сломаешь ли какой из старых. Но периодически, все таки, что-то ломаешь. И есть еще несколько моментов. Особенно, что касается прав, все время забываю раздавать права. Хорошо, бы перед вытаскиванием кода в боевую базу пробежали бы тесты, создали записали провели документы, под разными правами. Рассчитали скидки и тд.

(66) а как ты представляешь себе тестирование кода? По-моему других способов пока не изобрели. Дёргаешь метод/класс с разными параметрами, и проверяешь, соответствует его работа ожидаемой или нет. Во многих языках даже есть специальные конструкции для проверки ожидаемого поведения - assert'ы
https://habr.com/ru/post/141080/

(63) Действие одно получить цену

(68) Что значит как?
BDD
Сказал прогеру что сделать
Он сделал
Запускаешь Ванессу, нащелкал тест
Запустил тест, посмотрел, чтобы он не упал

(69) действие в коде это не бизнес-действие. Рассчитать зарплату тоже одно действие, только под капотом десятки тысяч строк

Декомпозиция, есть такое слово
1. Рассчитать зарплату
1.1. Рассчитать неявки
1.2. Рассчитать повременную оплату
1.2.1. Получить норму по графику
1.2.2. Определить количество фактически отработанных дней
1.2.3. Получить оклад
...
1.3. рассчитать сдельную оплату
2. Рассчитать НДФЛ
3. Рассчитать страховые взносы

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

(71) Вот именно
И нахрена мне тест проверки функции ПолучитьДанныеРасчетаПоСпискуСотрудниковСОтсутствиямиИНачисленнымиИПеречисленнымиЗарплатнымиНалогами?

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

(71) Да что же ты как уж на сковородке вертишься. Конкретный пример, и ты не можешь его решить с помощью TDD
Или если пример не входит в логику TDD то это неправильный пример и его нужно игнорировать

(73) Да, конечно
И что?
Ты и в TDD исчерпывающий набор тестов не напишешь
Зато в BDD тесты полезные, понятные пользователю и наращиваемые
И заставляют прогера думать головой, а не писать "под тесты"

(72) потому что гораздо надёжнее проверять поведение частей алгоритма, чем всего целиком. Ну запустил ты свой тест, проверил что запрлата посчиталась неправильно. Дальше что? Только лопатить код. А ошибка могла быть в какой-то одной несчастной функции, которая возвращала неправильное значение. Но чтобы найти эту функцию, тебе придётся пробежаться отладчиком через половину конфигурации. Такая вот разная локализация ошибок. Без мелких покрывающих тестовы ты будешь только знать, что у тебя что-то неправильно работает, но ещё не будешь знать, что конкретно неправильно работает. Для выяснения причин тебе потребуется много часов. А будь у тебя тест, покрывающий код, он сразу вывел бы тебя на эту функцию. Чувствуешь разницу?

(74) твой пример прекрасно ложится под TDD. С чего ты взял, что тут TDD спасует?

(77) так приведи как это реализовать с использованием процедуры с 1 параметром и поясни как тест проверит корректность полученных данных

(75) "Ты и в TDD исчерпывающий набор тестов не напишешь"

Как раз-таки напишешь

(79)
Ну вот у меня 12 тысяч позиций, 4 видов цен и все в разных валютах, как правильно написать тест чтобы он подтвердил корректность получения всех данных на любое число

(62) Ел. А вот ты не похоже, что ел.

(78) всё просто. Одна процедура с десятью параметрами превращается в несколько процедур с двумя-тремя параметрами каждая. Все десять параметров тебе не нужны в один момент времени. Конечно, код может грести и все 10 параметров за раз. Но его легко реаргонизовать так, чтобы в один момент требовалось только пара параметров. В винде десятки миллионов строк кода, но вряд ли ты там найдёшь метод с сотянми параметров

(80) Нужно покрыть тест кейсами все основные случаи и желательно большинство крайних. И это гораздо меньше, чем 12000 * 4 * 3(валюты). Это 10-15 кейсов.

Ты же не доказываешь теорему Пифагора для отдельно дла каждого из возможных значений a, b и c.

(80) твой алгоритм раскладывается на части. Тебе нужно по отдельности проверить:
1. Что курс валюты получается корректный
2. Что цена получается корректно
3. Что цена на курс перемножается корректно
...
для этого впринципе не обязательно пропускать все 12 тыщ позиций через тест. Декомпозируй и властвуй!

(84) "Что цена получается корректно" - как? Описать все 12 тысяч * видцен* дату
Я не понимаю как написать тест, чтобы он проходил на любой базе и на любых данных

(85) разумеется, нет. Достаточно проверить несколько позиций

(86) что
А. не гарантирует 100%
Б. не гарантирует что завтра этот тест пройдет, так как исходные данные в базе могут быть изменены, а значит завтра, когда я начну пилить бонусную программу, мои старые тесты будут неактуальны и я не могу гарантировать их корректность

(87) если данные изменятся, тест сразу же выпадет в ошибку. И ты будешь знать, что появилась проблема именно в получении цены. Всё, вот она твоя ошибка, локализована. Тест сработал

(76) Рукалицо
Ладно, забей

(79) Клиника какая-то, упоротость 80-го уровня

(81) И что мне с твоих подозрений?
А мне непохоже, что ты ел
И что?

(88) А если все прекрасно проверилось, ошибок нет, а список контрагентов при выборе из списка почему-то пустой?
Что делать?
Где в твоих проверках неправильное использование правильно работающих процедур и функций?

(90) что упоростость? Писать покрывающие код тесты? Так всё взрослое программирование делает. Только до 1с пока что не дошло

(92) вот что ты такой нудный? Твоя ванесса тебе покажет, что документ стал неправильно проводиться. Всё. Дальше сам ищи проблему в 10 тысячах строк кода. А модульное тестирование сразу ткнёт пальцем, что вот эта сраная процедура перестала правильно работать. Модульное тестирование в любом случае копает намного глубже, чем ванесса. В иделае они должны дополнять друг друга

(94) Что документ перестал проводиться, это и пользователь может сказать. Ванесса не нужна для этого :)

(93) Упоротость в твоем игнорировании аргументов, которые я пишу

(96) твои аргументы опираются на твоё непонимание TDD, да и вообще модульного тестирования

(94) Блеать! Ничто ничего не покажет, код идеально верный, ни единой синтаксической ошибки!
Но просто прогер вызвал идеально работающую функцию там, где ее не нужно было вызывать
Все!
Что будешь делать?
Рассказывать пользователю, что да пошел он в жопу со своими странными проблемами?
У тебя же твой код работает без ошибок, верно?

Еще раз
Главная цель тестирования — не дать коду, приводимому к ошибочному результату, попасть в прод
Ошибочному результату с точки зрения *пользователя*, а не *программиста*
Пользователю на проблемы программиста поссать с высокой колокольни
Если ты программист и хочешь сам себе написать сначала TDD, а потом уже ваять код (со вложенными в него TDD-тестами) — удачи, кто тебе запретит-то
Но это нихрена ни разу не отменяет твоей обязанности покрыть свое творчество BDD-тестами
Потому что именно BDD, а не TDD, понятно и близко пользователю, именно BDD, а не TDD, является тем, что сокращает количество визитов к тебя пользователей с битами и звонков недоумевающего охреневающего начальства
Если ты бессмертный упоротый индивид с IQ 40, продолжай использовать TDD без использования BDD, чо

Давай попробуем на пальцах. Твоя машина перестала заводиться. Какая диагностика лучше: которая скажет "проблема под капотом", или которая укажет на конкретный агрегат автомобиля?

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

(98) "Главная цель тестирования — не дать коду, приводимому к ошибочному результату, попасть в прод"

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

(99) Та, которая скажет мне о проблеме на этапе производства
Только TDD в твоем случае — это нихрена не "проблема в конкретном агрегате"
TDD — это то, что твой пепелац соответствует изначально написанным техническим тестам
С какого хрена ты решил, что раз у тебя есть TDD, то это теперь ответ на любую ошибку, что проблема именно там-то и там-то, я в душе не подозреваю

(100) модульное тестирование сделает это гораздо эффективнее. Не тупо скажет "в РТУ проблема" а скажет "проблема в РТУ в процедуре Хуяк()"

(101) А стартер, блеать, работает как часы, прикинь!
И вообще все работает как часы
Но автобус не едет
Что будешь делать?

(102) ты всё-таки почитай про модульное тестирование

(103) Ты идиот что ли?
Я тебе говорю, я открываю список контрагентов, он пустой
TDD-тесты ничего не говорят
Что делать?

Еще раз, никто тебе не запрещает писать TDD-тесты, но пользователю они нахрен не нужны, ему нужны BDD-тесты

(105) Что именно мне почитать, раздел, в котором говорится, что TDD-тесты нужны, а BDD-тесты не нужны? Ссылка на такой текст дашь?

(104) не фантазируй. Если диагностика проверяет конкретно стартер, и проверка показала проблему, то дело наверно в стартере

(107) для начала просто выясни для себя, что такое TDD

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

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

(110) как всё запущено... Считай что диагностика снимает стартер, подаёт ток из гарантированного источника. В этом и суть модульного тестирования. Проверяется конкретный кусок кода без привязки к другим кускам кода.

ЗЫ проводку проверяет уже другой тест. Он её также снимает и подключает к источнику напряжения

(111) заканчивай ты уже. Программист САМ пишет тест для проверки своей процедуры. Никто лучше программиста не знает, что и как должна делать процедура

(112) А ничего, что то, что ты описываешь, это 3 рубля на разработку автобуса и полмиллиона рублей на проверку всего, чего только можно?
А ничего, что проверка одного автобуса перед рейсом — это месяц работы целого автопарка, который будет все снимать, подключать на стенд, проверять, собирать обратно, комбинировать и т. д.?

(114) а я тебе ещё раз говорю, читай что такое TDD. Там не то что нет дополнительных затрат, там экономия

(113) Да не важно, пусть сам пишет, главное не в этом, главное в разнице самих подходов
TDD-тесты проверяют на ошибки работу процедур/функций и понятны только программисту
BDD-тесты проверяют на ошибки пользовательский сценарий работы и понятны всем

(116) между ними колоссальная разница в глубине диагностики

(117) И чо? К чему это? BDD-тесты нужны?

(118) нужны, но не достаточны. Вот сломался у тебя ЗУП, расчет зарплаты не те цифры выдаёт. BDD указало на проблему. Ок, в прод косячный код не пустили. А дальше что? Брать в руки отладчик и привет долгим часам нудного поиска ошибки.  Через 30 часов нудной отладки ты выяснишь, что косячила одна процедура. А будь у тебя модульный тест, он эту косячную процедуру нашел бы за секунду

Мдя.. Спорят двое... Один говорит, что небо синее, другой - что пиво не охладилось...

(119) Аллилуйя! BDD нужны!
На этом и остановимся

(121) т.е ты весь топик поливал TDD только для того, чтобы констатировать нужность BDD?

Каждому человеку хочется ощущать себя правым хоть в чем-то.
Но некоторым этого мало. Им нужно кого-то другого, что тот неправ.

(123) нужно *убедить* кого-то

(122) Да нет, в (28) задал тебе вопрос, а ты его проигнорировал
А вопрос как раз подразумевал крайне небольшую ценность и чрезвычайно высокую трудоемкость TDD
И это при том, что в подавляющем большинстве случаев все прекрасно решается BDD

(125) а с чего ты взял, что трудоёмкость высокая? Всё с точностью до наоборот, при грамотном применении TDD разработка идёт быстрее, чем без оной. И ценность у TDD очень высокая. Гораздо выше, чем у BDD

Но ты не нов. Ещё лет пять назад 1сники наперебой кричали, мол нафига вообще это автоматизированное тестирование. Почему-то всё проходит через стадию отрицания и сопротивления

(126) Ценность небольшая, потому что обычно код на безошибочность проверяется один раз, в процессе его написания
Проверять постоянно, не перестала ли работать функция, которая еще вчера работала, достаточно странно
Это такая своеобразная гигиена, написал/поменял код — проверь его на безошибочность

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

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

(127) Автоматизированное тестирование в 1С — это BDD, нахрена ты сейчас пытаешься натянуть сову на глобус, подменяя понятия?
Кто-то свой код даже в пользовательском режиме перед отдачей пользователю не проверяет, типа да ладно, и так сойдет

(128) вот тут ты сиильно заблуждаешься. Код будет меняться снова и снова, раз за разом. Каждый раз изменения должны тестироваться. Надеюсь необходимость тестирования доказывать не нужно?

(129) так я про то и говорю, что лет пять назад 1сники плевались на BDD, примерно как ты сейчас плюёшься на модульное тестирование

(130) Пример, дай пример, хватит софистики

То есть если пять лет назад кто-то плевал и на BDD и на, например, пидарасов, а сейчас на BDD перестал плевать, то неизбежно лет через пять жди нового пидараса?
Ммм, логика

Или ты увидел похожие буковки в TDD и BDD и на основании этого тут же сделал выводы о том, что их ждет идентичная судьба?

(130) "Каждый раз изменения должны тестироваться" - для этого TDD и нафиг не нужен

(131) нет, ты не понял. Как я уже неоднократно писал, 1сная отрасль отстаёт от взрослого программирования на 10-15-20 лет. В 1с только-только начали использовать автоматизированное тестирование, да и то пока что точечно, а во взрослом программировании автоматизированное тестирование на марше годов так с 90-х. Сейчас во взрослом программировании модульное тестирование (юнит-тестирование) это де-факто стандарт, им пользуются все уважающие себя компании и разработчики. Но ты, с приветом из 1сного отставания, кричишь о ненадобности модульного тестирования

(132) а тесты после 2-3-5-10 изменения у тебя откуда должны появиться?

(133) У тебя есть статистика? Взрослые люди говорят что во всем мире единицы используют TDD при разработки. Даже отцы основатели  TDD и то со временем признают частично ошибочность своих суждений

(134) Из BDD

(133) Ладно, понятно, примера от тебя не получишь, только пистеть способен

У меня есть задача выгрузить реквизиты контрагента в файл для загрузки его на сайт.
Т.е. на входе контрагент, на выходе текстовый документ.
В классическом программирование я должен взять выходной файл и проверить валидность данных (ну чтобы в поле почта была почта, а не телефон, а ИНН состоял как минимум из 10 цифр). В TDD я напишу тестирования файла и чтобы и проверяю валидность

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

(135) я говорю про модульное тестирование, и TDD как частность этого тестирования. Сходи на форумы не 1сные, спроси нужно им или нет модульное тестирование

(136) вот внёс ты точечные изменения в модуль на 100k строк кода, BDD показывает, что что-то сломалось. Дальше что?

(139) У тебя какое то странное представление о BDDи TDD

(138) "Вот только бизнес логика заставляет меня встроить еще десяток проверок на корректность первичных данных, иначе такая фигня получается, хотя с точки зрения TDD тесты проходят"

кажется я тебе уже писал, что ты тоже в TDD ни в зуб ногой

(139) LOL
Дальше ты смотришь свой говонокод, что ты там такого наменял, епта

(140) судя по твоим каментам, у тебя представление о TDD куда страннее

(0) Очередная серебренная пуля. Нихрена это не поможет. Только больше времени будете тратить.

(142) а если изменений на 10k строк и их вносили одновременно семь человек? Все 10k строк будешь перепроверять?

Или озадачишь всех семерых, чтобы каждый из них потратил несколько часов на перепроверку своего кода?

С точки зрения теста они абсолютно одинаковы что тесты для BDD что для TDD. Разница в подходе т.е. ты ничего не знаешь что будет происходить внутри этого модуля при TDD и можешь максимум прописать тесты для заранее подготовленых параметров. А с точки зрения BDD я уже знаю логику работы и пишу тесты не только для выходных параметров но и проверка ситуаций которые могут возникнут внутри модуля.
Т.е. я легко могу использовать тесты из TDD в BDD программирования, а вот более широкие тесты из BDD в TDD я не могу использовать, потому что незнаю что у меня будет происходить внутри

(147) "С точки зрения теста они абсолютно одинаковы что тесты для BDD что для TDD"

По-сути это разные методики с разными подходами к тестированию. Более того, их вообще используют разные люди. TDD это для разработчиков, BDD больше для аналитиков, пользователей

(145) А если у тебя завтра на лбу рог вырастет?
К чему эти тупые примеры?
Приведи нормальный конкретный пример

(149) оп-па-на! Т.е. групповая разработка и динамичные изменения это тупые примеры? Ну я прям не знаю, что тут сказать...

(150) Да ты дебил что ли?
Тупой пример — это когда берем сферического коня в вакууме, которого в течение недели семь рыл одновременно переписывают в говно
Хороший пример — это когда ты говоришь про конкретную задачу (например, доработка загрузки документов из банка) и когда нет дебильных допущений типа семи говнокодеров, одновременно переписывающих функционал в усмерть

(151) шта? Ты хочешь чтобы я привёл тебе пример модульного тестирования, которого впринципе нет в 1с и которое не позволяет выполнять концепция платформы?

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

(152) Ты либо совсем кретин либо троллишь
Я хочу, чтобы ты мне привел пример ЗАДАЧИ, в которой нужно доработать код, который вчера работал, а после доработки может поломаться и где чрезвычайно полезны будут TDD, потому что ничего другого здесь не спасет отца русской демократии

(153) а на крупных проектах только так и работают. У нас человек 20 "ушатывают" одну конфу, зачастую двое-трое долбят один и тот же общий модуль

(154) ЛЮБАЯ задача разработки прекрасно ложится под TDD. Хватит нести истеричную ахинею. И погугли уже наконец-то что такое TDD. Вот тебе даже видос, как оно происходит
https://www.youtube.com/watch?v=y8TcPr73Bwo

(155) Ладно, я понял, пример ты привести неспособен

(156) в (58) привёл простейший пример, но ты его даже не понял

(157) А, ну наконец-то, гора родила мышь, блеать, не прошло и полдня

+(158) Отлично, смотрим пример из (58)
Как я уже сказал, ценность небольшая, потому что функция крайне простая, проверена единожды в процессе ее создания
Вероятность того, что она поломается из-за изменений какого-то другого кода — минимальна
Поэтому в дополнительных тестах я смысла не вижу

+(159) Это плохой пример, берем другой или что?

Почти всегда BDD это сценарные/поведенческие тесты. Зависят от данных и выполняются значительное время.
TDD же легкие тесты, которые дают моментальную обратную связь:не сломал ли свой код или соседский в каком-то левом модуле.
Спор ниочем. Нужны как одни, так и другие подходы.
Нужно быть дебилом (раз пошла такая терминология) применять BDD на этапе разработки и ждать n-часов/минут, при каждом коммите.

Пишите исчо, интересное чтиво однако 😏 А так соглашусь, 1с, даже 8, это как убогенький динозаврик, отстает так лет на 15 от современных техов. НО! Альтернатив, как таковых, толковых не наблюдается, так что юзаем то что есть и молча киваем. Ну нет там возможности tdd нормально заюзать, но что же поделаешь. Это не опенсорсный продукт, так что такой возможности, быстрее всего, и не появится. Да, язык никакой, что можно было бы одной строкой сделать, приходится терять время и кнопки давить. Да и редактор так себе, с тем же отставанием. Модульность никакая, на простые, казалось бы, решения, приходится "велосипедить". Да и тот же конфигуратор хотелось бы в темных тонах, а не цвета "неожиданности", что бы глаза меньше уставала, но для этого просто еще лет 15 нужно подождать, и все будет... в общем, как и сказал, альтернатив толковых пока нет, так что пользуемся, и дружно киваем 😎

(161) Что такое этап разработки? Когда ты делаешь пулл реквест — это все еще разработка?
И что дебильного перед помещением своих доработок в мастер проверить их на работоспособность?

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

(61) "Нужны как одни, так и другие подходы"

Повторите, пжалста, погромче. Для сидящих на последнем ряду

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

(165) Ты бы лучше пример нормальный привел

(164) Проверка на входящих данных не гарантирует корректность

(145) про диагностику автобуса: если изменения вносили 7 человек, этож 7 разных комитов(в dev-brachах), на каждый из которых можно натравить BDD. который из них упал тот и валенок. или проблема в большом времени BDD?

(163) Перед помещением проверить? Можно, но нужно:
- иметь актуальную тестовую базу. Хорошо, если она есть и небольшая. А если большая или данные тебе не положено видеть?
- сборочный конвейер. Прикольно если у всех есть jenkins и docker

У ТС каша в голове. Он почему-то (как, впрочем, и другие адепты) ставит знак равенства между "тестирование" и TDD.
Но это вещи вообще из разных координат.

(166) не будет быстрее. Возвращаясь к тому же примеру

Во время отладки проверишь ты на входящей дате 03.10.2020, функция вроде бы работает. Но потом выяснится, что праздничные дни она неправильно переносит. СледующийРабочийДень(31.12.2020) у тебя возвращает 01.01.2021 вместо 11.01.2021. Но ты узнаешь об этом только от юзеров, вышедших на работу после праздников. А так ты заранее можешь проверить на некоторых пограничных или особых входящих данных, не задрачиваясь на перезапуск отладки/перепроведения и иже с ним. А так твой код легко и просто проверяется на разных наборах данных

СледующийРабочийДень(03.10.2020) = 05.10.2020
СледующийРабочийДень(20.10.2020) = 21.10.2020
СледующийРабочийДень(31.12.2020) = 11.01.2021

Я, кстати, не видел пока ни одного адекватного способа тестирования СКД.

(168) Дяденька не понимает, что даже в его примере может быть 2022 год или наоборот 2018 год
Или в регистре не будет каких-нибудь дат, а в тестах этот случай не будет учтен и алгоритм вернет не то, что нужно
Или еще 100500+ возможных упс

Но виновата, да, 1С, что не сделала поддержку нормальных TDD-тестов, ага

(171) я не ставлю между TDD и тестированием знак равенства. С чего ты взял?

(174) так твоя беглая проверка на первых попавшихся данных учтёт намного меньше случаев. Точнее всего один случай

(170) >>иметь актуальную тестовую базу. Хорошо, если она есть и небольшая. А если большая или данные тебе не положено видеть?
Она есть
Она небольшая и недостающие тестовые данные в нее набиваются Ванессой
По фигу на размер
Права есть

>>сборочный конвейер. Прикольно если у всех есть jenkins и docker
У нас есть, обращайся

(171) +1

(172) Ага, ты типа умный, а кругом имбецилы, хи хи
Не сцы, я на 31.12.2020 проверю, не дурнее тебя чай

(179) не проверишь, ибо тебе для этого нужно будет создать и заполнить отдельный документ с датой 31.12.2020, и ещё миллион лишних движений. Тут не вопрос ума, тут вопрос трудозатрат на такую проверку

С удовольствием читаю ветку. Очень интересно. Но не могу понять простую вещь. Наверное потому, что не юзаю ни первое, ни второе. Никак не могу понять почему PR рассказывает, что его тесты будут учитывать большинство ошибочных ситуаций которые могут произойти, а TDD тесты с окажутся тупыми? Потому, что TDD тестов надо больше или потому, что BDD методика обладает более широкими возможностями? Ведь как я понял в BDD тоже юзер не будет писать "В этом поле я хочу видеть след. рабочий день. Да да да и после 01.01 должно идти 07.01 а не 02.01 как в прошлый раз". Он просто напишет "В этом поле я хочу видеть след. рабочий день". Все. То есть маху дадут оба подхода. Или где я ошибся PR?(можешь дразнить меня дебилом, я не обижаюсь)

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

(180) Ага, да, ты через TDD проверишь, а я через отладчик нет, да, все так и есть

(181) Тут просто.
БДД показывает "функционал не работает."
ТДД показывает "не проходит вот этот конкретный тест"

Если в бдд не заложена проверка на рабочесть - он ничего не покажет.
Если тдд не покрыл нужный кусок кода - он тоже ничего не покажет.

И да. Даже если все т из тдд показывают зелёный, это не значит, что пройдут все бт

(183) В тдд у тебя будет 100500 тестов с разными данными. А тебе в отладчике придётся все эти 100500 значений руками каждый раз вводить.

(181) Да тут странный холивар, и поэтому интересен :) Как по мне, тестирование, это довольно обширное, общее, понятие. А TDD просто подход к разработке, когда сначала пишутся тесты, какой результат у нас должен быть, а затем под них код, дающий этот результат. И, естественно, это по времени более затратно будет. Зато дальнейшая поддержка кода намного проще, даже другим разработчиком. И само собой, в более-менее серьезном проекте, ни одни тесты не покроют его на все 100%. Где-то чего-то потом вылезло, ну дописали мы на это дело проверку, и все дела, пусть работает дальше. Зато запороть код вмешательством уже намного сложнее. Где-то чего-то поправил, прогнал тесты, проходят, значит все ок. Но читать топик интересно. Лишь бы одеяло не порвали :)

(181) Я не утверждаю, что BDD-тесты будут учитывать большинство ошибочных ситуаций
Я утверждаю, что они будут покрывать определенные пользователем критические операции
И объем этих тестов можно наращивать по мере необходимости и по мере выявления ошибок
А TDD-тесты к пользовательским сценариям не имеют никакого отношения
И поэтому непонятно, какие TDD-тесты очень важно написать и поддерживать, а на какие в принципе можно подзабить или вообще положить с прибором

В BDD, кстати, пользователь на Геркине напишет именно как раз, что он ввел в такое-то поле 31.12.2020, после чего в другом поле стало 11.01.2021
Геркин не настолько умный, чтобы оперировать понятиями "Следующий рабочий день"

Дразнить я тебя не буду, с чего бы

(184) В BDD не просто "Не работает", там известен шаг, на котором все накрылось медным тазом
А у нас еще и скрин экрана в момент, когда все квакнуло

(183) тогда у тебя не получится быстрее. Вот мы и начинаем открывать плюсы модульных тестов)

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

(185) Да, это единственно интересный сценарий, я думал про него
Правда, Конструктор про него промолчал, поэтому я не стал за него искать аргументы в пользу TDD
Но тут есть нюанс
Для 100500 вариантов нужно 100500 верных ответов, ага

(191) Эти верные ответы записаны в тестах в виде ассертов. А не картинок.

Это все круто конечно, ТДД, БДД, тестирование, скрамы хренамы, но вот смотрю я на обновления софтин в своем айфоне, и вижу, что "тут мы исправили...", а "тут мы в порядок привели", и все в таком духе. Причем одни и те же релизы обновлений могут выходить по нескольку раз за короткий промежуток времени.
Если речь идет о серьезной разработке серьезных систем для серьезных контор, то может быть такие технологии и важны, но в целом в 1с - кому это уперлось?
Сеебстоимость считает? Баланс сводит? ЗП считает там как-то ... И привет)

(186) Я не утверждаю, что таких нет, но пока не услышал примеров, когда TDD было бы интересно и оправдано

(191) я тебе весь топик пытаюсь объяснить, что TDD это вжух - и прогнал свеженаписанную функцию через свеженаписанный тестик с множеством вариантов

(189) Получится
Потому что мне не придется вообще в принципе предусматривать вариант работы кода в режиме тестов
И потому что я тупо в отладчике за 15 секунд вычислю, что мне вернет функция для такого-то параметра
И забуду про эту функцию, возможно, на всю оставшуюся жизнь

(189) Кстати, а кто будет писать TDD-тесты для TDD-тестов?

(190) Не покрывают
Но и работают не по принципу булево, типа все прошло или где-то упало
В большинстве случаев информации более чем достаточно, чтобы быстро понять, почему тест упал

(192) И кто эти ответы вычисляет?
И не пользуется ли он для их вычисления этой же функцией, для проверки которой он их вычясляет?

(195) И где же ты берешь эти вжух-проверки? Кто их наполняет?

(196) "И потому что я тупо в отладчике за 15 секунд вычислю, что мне вернет функция для такого-то параметра"

С единственным параметром типа дата да, можно легко проверить. А если будет одна дата и одна ссылка? Уже возможностями отладчика не отобъешься...

(197) никто. Зачем их писать?

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

(200) разработчик сам пишет проверки. Это же TDD - разработка через тестирование. Т.к. гранулярность у тестов большая, то большинство проверок не сложные

(199) А зачем вычислять результат теста функцией, которую потом же им и проверять будем ) Я вот думал результат вообще в таких случаях "не вычисляется". Входящие параметры: 2, 2. На выходе что должно быть: 4. Фсё. Передали параметры, получили ответ, сравнили. И по поводу "интересно и оправдано", тут либо сам решаешь, либо требование такое. Я вот ни разу никаких тестов не писАл. По времени экономия. Но если настроен упростить жизнь тому, кто после тебя будет код поддерживать, да и самому, если проект объемный, можно было бы. Но пока не писАл :) И вообще, многие тесты часто и пасАть то странно. К примеру в том же javascript, не будет же на каждый чих писать что 0.1 + 0.2 равен строго 0.3, хотя и не мешало бы ) Тут еще и от компетенции разработчика все зависит. В общем не знаю о чем тут даже спорить )

(201) А примера с не единственным параметром я не увидел, так что не понимаю, зачем мы обсуждаем сферического коня в вакууме

(201) Что значит зачем писать правильные ответы?
А с чем ты собираешься сравнивать результат функции?

(201) А, прикольно, че
Написал функцию получения следующего рабочего дня и тут же быстренько наипенил 100500 вариантов входных параметров и верных ответов

(202) Ну то есть быстренько нахреначить 100500 вариантов с параметрами и верными ответами — это минутное элементарнейшее дело?

(203) ну пускай будет вот так

ВозрастФизлицаВГодахНаДату(e1cib/data/Справочник.ФизическиеЛица?ref=869d0050568b35ac11e4ce0a151c2318, 12.02.2020) = 42
ВозрастФизлицаВГодахНаДату(e1cib/data/Справочник.ФизическиеЛица?ref=869d0050568b35ac11e4ce0a151c2318, 13.02.2020) = 43
ВозрастФизлицаВГодахНаДату(e1cib/data/Справочник.ФизическиеЛица?ref=92f10050568b35ac11e4f4cff814af7d, 16.08.2020) = 29
ВозрастФизлицаВГодахНаДату(e1cib/data/Справочник.ФизическиеЛица?ref=b3380011955cba6b11df72ece91d1737, 16.08.2020) = 29

Или вот так

ФамилияИмяОтчествоФизлицаНаДату(e1cib/data/Справочник.ФизическиеЛица?ref=869d0050568b35ac11e4ce0a151c2318, 12.02.2020) = "Иванов Иван Иванович"
ФамилияИмяОтчествоФизлицаНаДату(e1cib/data/Справочник.ФизическиеЛица?ref=92f10050568b35ac11e4f4cff814af7d, 12.02.2020) = "Петров Пётр Петрович"
ФамилияИмяОтчествоФизлицаНаДату(e1cib/data/Справочник.ФизическиеЛица?ref=b3380011955cba6b11df72ece91d1737, 12.02.2020) = "Сидорова Софья Павловна"
ФамилияИмяОтчествоФизлицаНаДату(e1cib/data/Справочник.ФизическиеЛица?ref=b3380011955cba6b11df72ece91d1737, 15.02.2020) = "Петрова Софья Павловна"

(204) Я говорил что на некоторые моменты просто вообще тесты писать странно, это раз. И про "быстро нахреначить" не совсем понял. Уже же сказал, при тесте есть входные параметры, есть результат, который должен получиться. Если тебе нужно проверить функцию получения следующего рабочего дня, ты для тестов его не вычисляешь. Берешь следующий рабочий день по факту, и сравниваешь с тем, что возвращает тебе функция. Было бы интересно, если бы написал свою методику тестирования, а то "не могу понять", как говориться ) Ты результаты для тестов вычисляешь теми же функциями которые и проверяешь что ли? Хм...

(207) О, прикольно, пример, в котором само собой разумеющееся, что функция без проблем определит физлицо по адресу
Действительно, все же так умеют, ничего специально для этого писать не нужно
И само собой, что проверка этой же функции только в отладчике в виде "ВозрастФизлицаВГодахНаДату(Справочники.ФизическиеЛица.НайтиПоКоду("001"), '20200212')" займет годы, если не десятилетия

(208) Про "быстро нахреначить" я говорю про то, что тут появился аргумент про 100500 проверок
Я и говорю, кто их и как готовит-то, эти 100500 вариантов?

Никакой своей методики у меня нет
Конечно же берется одно или несколько действий и вручную на Геркине определяется, что должно быть после этих действий
Только никаких 100500 проверок нет, есть одна, две, может три проверки, но не 100500 точно

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

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

да и если код у тебя по-человечески организован, никаких 100500 проверок не нужно. Для той же функции ВозрастФизлицаВГодахНаДату() тебе достаточно проверить на паре обычных людей на разных датах (до д.р., после д.р., в сам д.р.), и на людях с "интересными" датами рождения (1 января, 31 декабря, 29 февраля). Этого должно быть достаточно. Вовсе не нужно пропускать через функцию всех работников предприятия

(210) Не знаю что за аргумент в 100500 проверок, то чем их больше, тем лучше. В любом случае, на 100% результат рассчитывать не нужно, потому как всегда что-нить да может вылезти. И да, результаты нужно заведомо правильные, и не важно как они получены. Если в цикле получаешь 100500 результатов для проверки, то тогда уж сядь и предварительно просмотри, верны ли они, иначе никак. В общем не знаю о чем тут и говорить-то, когда всё очевидно.

(211) Не останется. А зачем?

Про еще сложнее опять сферический конь в вакууме
Типа я вот в TDD все мухой делаю и получаю мегаништяки, а ты в отладчике упашешься до седьмого пота
Давай пример, тогда и обсудим и трудоемкость написания TDD и сложность вычисления в отладчике и полезность TDD для потомков

Но как я говорил, TDD неплохо дисциплинирует, заставляет думать над сигнатурой методов и упрощать её при при возможности. Скорее всего ты из функции ВозрастФизлицаВГодахНаДату() выделишь функцию более нижнего уровня ВозрастНаДату(ДатаРождения, ДатаПроверки), и напишешь тесты уже для этой функции. А для функции ВозрастФизлицаВГодахНаДату() напишешь более простую проверку

ВозрастФизлицаВГодахНаДату(e1cib/data/Справочник.ФизическиеЛица?ref=869d0050568b35ac11e4ce0a151c2318, 12.02.2020) = Тип(Число) И > 0
ВозрастФизлицаВГодахНаДату(e1cib/data/Справочник.ФизическиеЛица?ref=869d0050568b35ac11e4ce0a151c2318, 13.02.2020) = Тип(Число) И > 0

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

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

(212) Вот именно
Вполне достаточно проверить несколько вариантов один раз, возможно даже в отладчике

(213) Ну так прочти (185) тогда что ли, там в первый раз про 100500 проверок

(209) Ты пойми, что TDD/BDD нужны ни только для тестирования функциональности, а для автоматизации программерской рутины.
Отдел программистов, пишущих свой кусочек, и не лезут в другие модули, запросто в отладчике/руками и любым другим способом проверят свое.
Но, когда они лезут в чужие модули, то для каждой своей(!) правки сложно тестировать чужой код из других модулей.
Идеально, когда так:
- лабаешь код с юнит-тестами (до или после - дело привкуса)
- закоммитился в DEV-branch (код и тесты)
- jenkins/teamcity/etc прогнал все ют (или не все - дело внутренней политики)
- в моменте получил обратную связь, что ничего не сломалось
- ночью или когда еще запустили сценарные тесты
- пулл реквест в main (мы же с 01.10.20 забанили термин master из-за BLM)
- полный комплект тестов и вот релиз.

Все зависит от масштаба разработки.
И да, любые подходы тестирования не 100% гарантия. Просто нужно жить с коллегами по принципу - "не ошибается тот, кто ничего не делает" + "вылезла хрень, написали тест под этот кейс"

(215) Бред какой-то, тесты ради тестов, какая-то никому нахрен не нужная мешанина из кода, обреченная на уход в небытие через неделю после написания
Скорее всего после прихода нового прогера и его общения с руководителем будет так:
— А что это за обработка "Запуск TDD-тестов"
— А, это прогер до тебя писал TDD-тесты
— Так там несколько тестов выдают ошибки, надо же срочно поправить
— Забей, у него это говно никогда толком не работало, вечно что-нить менялось, а тесты он не обновлял

(221) Вот ты себя и описал в лице этого начальника. Поэтому в бит и плюются )))

(217) эти принципиально разные варианты всегда могут быть разбиты на отдельные составные части. Если для функции верхнего уровня РассчитатьЗарплату() возможны 100500 вариаций входных параметров, то для функции более низкого параметра РассчитатьПроцентОтБазы(База, Процент) вариаций будет намного меньше. Только вот 1сники никогда не проверяют РассчитатьЗарплату() на 100500 вариаций, да это и физически не возможно. Скорее всего эталонным будет вообще один документ, и в функции нижнего порядка попадёт совсем мало значений. Покрытие будет крайне низким. А с модульным тестами ты проверишь каждую функцию на десяти-двадцати входных вариантах. И проверка пройдёт очень быстро. Тебе не придётся перезапускать адронный коллайдер тыщу раз

(220) Когда правишь чужой код, то да, нужно сначала въехать
Но въехать нужно в любом случае, независимо от наличия TDD-тестов
Вообще в данном случае куда более ценным является читабельный самодокомментируемый код

А, и да, на BLM мне наплевать с чуть более высокой, чем самая высокая, колокольни, так что мастер

(220) По поводу не панацея согласен
Просто что точно не стоит делать — это писать тесты, которыми никто не будет пользоваться, потому что будет (221)

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

(221) ничего никуда не уходит. Всё аккуратненько лежит в определенном месте, и используется в будущем повторно. Твои проблемы надуманы. А модульное тестирование настолько стандарт в программировании, что современные IDE сами создают папки для тестов, сами подтягивают нужные для тестирования зависимости, и сами генерят заготовки тестов. Создал пустой проект, а у тебя уже есть служебная директория Test с заготовками

(223) У меня нет цели покрыть тестами код
У меня цель — покрыть тестами пользовательские сценарии работы

(224) тесты кода позволяют лучше понимать код. В тестах ты сразу увидишь, что ожидается от кода

(228) тогда тебе придётся постоянно иметь дело с трудноотлавливаемыми ошибками

(229) LOL
В названии процедур, функций и переменных, в комментариях я вижу, что ожидается от кода

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

И еще - берем проект с github'а и пытаемся разобраться с тем, как пользоваться API этого проекта.
Что мы делаем? Читаем доку и лезем смотреть тесты - тесты дополняют доку, а иногда спокойно заменяют.
Нет тестов? Епт, курим доку до посинения и надеемся, что в доке отражены все нюансы.

(230) Не такие они уж и трудноотлавливаемые
Они зачастую не более трудноотлавливаемые, чем в коде, покрытом TDD-тестами
И отлавливаю я важные ошибки, которые реально поломают работу пользователя
А с TDD-тестом хрен пойми, важный он или нет

Ладно, я смотрю, ты глух к аргументам и (171) тебе не зашло

(232) Все верно
Только TDD — это неуловимый Джо, хрен протухнет, зато никому нахрен не нужен
А BDD может меняться, да, зато приносит реальную пользу

(233) А что, обратный вариант невозможен что ли?
Что в доке все есть, а в тестах нихрена

(236) Ты зациклился на недостатках.
Подходы и инструменты помогают минимизировать программерские и пользовательские проблемы. Как конкретный индивид будет пользоваться инструментами зависит от его способностей.
Если тесты пишутся только, чтобы продавать услуги (у нас есть тесты, мы используем передовые подходы и прочий инфоцыганский треп), то ничего не поможет ловить ошибки.
А если команда заинтересована в качественном продукте, то они будут делать все, чтобы у них были юнит, сценарные и интеграционные тесты, и находились в актуальном актуальном состоянии.

(237) Просто я не думаю, что TDD полезны всегда и везде
Иногда да, в некоторых случаях да, но не более

(238) Если степень применимости скорректируешь, то с твоим высказыванием согласятся все мистяры )

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

(226) он имел в виду, что если в БИТе такие бездарные руководители, которые за 200 постов не смогли понять зачем нужны TDD тесты, и как они работают, то понятно откуда неуважение к этой организации.

(239) Ну, например, функция со сложным матрасчетом, когда ты сам не уверен, что нигде не налажал

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

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

Или когда ты пишешь ПО для военных или для АЭС

В общем, есть вагон вариантов, когда TDD уместен и полезен
Но глупо в любом случае на каждый чих сразу бросаться писать многочисленные 100%-нопокрывающие код TDD-тесты

(241) Спасибо, кэп, суть слов я понял и без подсказки
Непонятно, с какого перепоя он (221) в (222) спроецировал на меня

(234) ошибка может быть мелкой, но приводящей к серьёзным последствиям. Да и странно такое читать от программиста. Типа ай, вот тут 2х2=5, но это мелочь, ничего страшного

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

(242) красавчик, мы в тебя верили )

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

(243) Потому что ты всю ветку ведёшь себя как руководитель из (221), обесценивая пользу TDD, хотя сам просто не понимаешь как это работает, а самое главное – не понимаешь главную пользу, при таком подходе намного труднее писать говнокод и легче совершенствовать код.

(242) Именно, TDD имеет смысл в серьёзных системах, работающих 24/7 например.

Там где минута простоя это миллионные убытки

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

А 1с к таким не относится )))

(248) ага, где архитеторыв, тестировщдики и прочие хрени...
много тут 1Сников которые в каждой конторе где они работают/обслуживают по нескольку 1с-человек над одним проектом работают?

(250) проектирование продукта и реализация в коде - они на разных уровнях. TDD - это про программирование, как бы последняя буква D на это намекает. Дизайн/проектирование из другой истории.
Чё начинаешь? )

(252) Всё так, в 1с TDD нужно большим командам, писателям типовых, например

кстати сейчас подумал почему типовые такие вечно косячные – там нет TDD )))

как будто в других местах работают другие люди, такие же программисты делают более качественные продукты, просто у них другие техники, в частности наличие TDD

(255) ТДД - это инструмент.
там имхо нет системности нормальной в ПРОМЫШЛЕННОЙ разработке и выпуске продукта.
при отсутствии (условно) плана работ - инструмент ситуацию не спасет., поможет малость, это наверное да. доски будут отрезаны ровно. но дом построен при этом криво ;-)

Так все таки если мы Тесты пишем на заранее подготовленных данных (поиск справочника по рефу),

А. Как эти тесты будут работать на боевой базе, где нет тестовых данных
б. Как они помогут в поисках ошибок если они проверяют только тестовые данные, а не реальные

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

Почему, согласно статистики, TDD снижает процент ошибки всего лишь на 40%, а не на 100%. Ведь мы сразу пишем тесты покрывающие 100% плюс у нас красивый, идеальный код, но даже это не спасает и от половины ошибок. В чем подвох?
К тому же почему у крупных компаниях есть статистика как полоджительного использования, так и отрицательного. Ведь TDD она же позволяет быстрее писать программы и главное без ошибок и красивый код, но Ишь ты, поди ж ты

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

(260) невозможно достичь идеального результата. Да и профит от TDD не только в уменьшении количества ошибок, там есть масса вкусных "побочных" эффектов, упрощающих жизнь с написанным кодом

+TDD это не столько про тестирование, сколько про разработку

ОФФ: Постарался прочитать всё )
Вспомнился монолог героя миниатюр Аркадия Райкина: "Пуговица пришита крепко? Претензий нет?" это TDD
"Но не на том месте..." это BDD
Вечная песня "профессиональных" программистов, что 1С-ники "недо.."
...
ИМХО. Применение каждого инструмента необходимо в конкретном контексте, проекте и т.д. Кто-то кусачками обходится при монтаже, а у кого-то целый баул различных приблуд. Зависит от объемов и необходимости. Если какой-то инструментарий не применяют, то либо дорого, либо неэффективно.
А теоретизировать можно до бесконечности. Если программиста не остановить, он будет дорабатывать до бесконечности. Не я это придумал )

(263) не совсем так. При модульном тестировании, и разработке через TDD в частности, код получается более покрытым тестами. Без модульного тестирования чаще как в том анекдоте про программиста на стрельбищах,промазавшего мимо мишени: "у меня все пули вышли, проблема на вашей стороне"

Имхо TDD вообще в первую очередь не про качество кода и защиту от ошибок, хотя "Test" в названии вводит в заблуждение. TDD позволяет программисту четко идти к результату и делать только то что требуется, а не распыляться в разные художества. Косвенно это влияет и на качество кода, но в первую очередь профит это производительность, о чем было сказано в (0). Хорошие прораммисты могут и без этого, но где взять на крупный проект исключительно хороших?

(262) Аллилуйя, наконец-то ты отделил мух от котлет, я уж думал, этого никогда не случится

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

(265) Да, и здесь есть одна огромная засада, я ее описал в (33)

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

(266) вообще-то я об этом написал ещё в (0)

(267) ты так и не понял суть модульного тестирования....

(270) Я правильно понял, что тебе не нравится отсутствие в разработках 1С модульного тестирования?

Конвейер вещь хорошая, но на очень крупных предприятиях. В малых проектах ("ларьках" ) ) вещь не нужная.

(268) ты прямо настойчиво не хочешь понимать, что такое TDD...

(270) Я тебе про то, что ты хоть обпокрывайся все TDD-тестами, это примерно как со всех сторон прикрыть голову самыми лучшими материалами, которые защитят тебя от пули в голову
А потом тебе выстрелят куда угодно, кроме головы, и ты будешь сидеть и удивляться, ну как же так, я же все нахрен на 200% покрыл тестами, ну как же они все-таки смогли меня достать?

(273) Я понимаю, что такое TDD
Я говорю, что, как правило, нахрен оно не вперлось

(275) Если бы ты понимал, что такое TDD, ты бы в этой теме не спорил :))

(273) Ты не одинок )
http://catalog.mista.ru/1c/articles/918528/

+(277) Мне понравилось фрагмент дискуссии из ссылки:"TDD - это всего лишь идеология использования тестов в качестве ТЗ. Формулируете требования, воплощаете их в тестах и только потом реализуете код, удовлетворяющий этим требованиям. Именно в таком порядке. Тесты могут быть говно, код может быть отстой, зато можно смело заявлять, что вы ведете разработку по TDD и это будет чистая правда."

https://tproger.ru/translations/test-driven-development-is-dumb/
Надеюсь не надоел со ссылками.) Но хотелось понять ради чего холивар

(274) совершенно оторванная от реальности аналогия. С модульным тестом функция проверится на 30 вариантах входящих значений, на 28-м выловит багофичу. Без МТ функция проверится на 2-х первых попавшихся значениях, а то коварное 28-е значение выявится только в процессе эксплуатации. Что автоматом удорожит ошибку

(280) Ну, если тебе даже эта аналогия не зашла, умываю руки, ты непрошибаем, оставайся при своем мнении

(281) ладно. Живи в своих заблуждениях

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

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

В чем проблема то? Вы тратите больше времени на написание постов на мисте, чем на написание обработки, в модуле обработки ваш код - в форме тесты. Чем не JUnit?

(284) на тру-языках всё автоматизировано. Например вот
https://ru.wikipedia.org/wiki/JUnit

в 1с пока ещё конь не валялся. Палки в колёса вставляет платформенная концепция, которая не позволяет запускать модульные тесты

(285) примерно так и приходится делать - выдрал код во внешнюю обработку и тестишь. Проблема в том, что такой подход не универсальный, быстро создаётся свалка из внешних обработок, среди которых хрен разберёшь какая и зачем. А в тру-программировании модульные тесты аккуратненько хранятся в иерархической структуре, для запуска не нужно открывать каждый файлик теста вручную. Простыми кликами можно запустить один тест для одного класса/метода, или группу тестов, или ветку тестов, или все тесты сразу... Самое главное, где основной код лежит, там он и тестится. Не нужно его куда-либо выдёргивать и как-либо переделывать для тестов, в отличии от обработок 1с

- Пап, а кем ты работаешь?
- Проджект менеджером на аутсорсинговых проектах.
- А как это?
- Ну, представь, мне звонит заказчик и говорит, что у его клиента из живота торчит копье и надо срочно что-то делать. Я иду к людям и спрашиваю, что можно сделать. Потом звоню заказчику и говорю, что надо достать копье, но это будет стоить 1000$. Он говорит, что дорого. Я опять иду к людям и спрашиваю, что можно сделать дешевле. В итоге мы за 500$ загибаем копье и красим его в телесный цвет.

(286) нахрен труязыки :-)
Концепция 1С себя оправдала в той области где мы живем.

(283) Смысл тестов в том, что они выполняются автоматически при каждом коммите кода. А так как в парадигме TDD коммиты будут очень маленькие, проблемы с кодом (и с тестами, если некоторые из них некачественные) будут выявлены максимально быстро.

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

(289) Ещё бы над модульностью поработали и средства разработки улучшили, так вообще не на что жаловаться :)

(291) В BDD таки да, спецаналитики и спецпродактовнеры :)

(290) если коммиты маленькие - то нахрена тесты? при маленьком коммите я при написании кода уже его протестировал в башке. на это у меня ушло 30 мин. мне заплатят за 30 мин - в нашей сфере 1сников. никто мне нахрен не заплатит за просту печформу 5 тыс когда я еще все это формализую в виде тестов не в голове, а формальных тестов. при этом эта печформа будет неизменной года три как минимум... с ценами 1500 супротив 5000 я буду неконкуретноспособен на рынке "моей"/нашей автоматизации. в 90% (имхо) проектов 1С ТДД/БДД просто не живет. На каких/нить камазах/гахпромах где хайлоад и цена ошибки в печформе - миллион рублей - ну да, может быть...

(292) да вроде ЕДТ как норм. только батарейки тяжелые ;-)

(294) А если над проектом не ты один работаешь, а человек 10? Ну понятно, конечно, что если ты фикси в одно лицо на каком-нибудь заводике, тесты тебе нахрен не впёрлись.

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

(296) ну так про то и речь. а так как в шаей области один "фикси" может вполне тянуть контору на 30-50 работающих с 1С - то на проетах с 10 человеками в команде - это уже реальный "камаз"...

(295) Ну, вон тут товарищи из БИТ говорят, что ERP ворочаться более-менее в ЕДТ начинает на топовом проце 8 ядер 32 ОЗУ. И при этом куча детских ошибок до сих пор не исправлены :(

(294) Ты посмотри со стороны среднекрупного франча - там параллельно могут идти несколько проектов, может самих по себе и не очень больших, но сразу. И уровень кадров невысок относительно, тут без всяких парадигм из тру-языков качественную потогонку не устроишь :)

(299) и не будут исправлены в обозримое время. разрабы в полях не живут...
с другой стороны если ошибка не исправляется долго - значит некритично.
главное чтобы ошибку БЫЛО ВИДНО в работе.

(300) проблемы франч-индейцев меня-шерифа не волнуют.. ;-)

(302) Во... то есть, объективно судить об этом вот всём ты априори не можешь :)

(280) Я не понимаю тебя, с одной стороны ты тестишь на 3-4 фиксированных данных (иначе как узнать что функция возвращает правильный результат)
С другой стороны ты пишешь о каком то " 30 вариантах входящих значений"
Я правильно понимаю что это теже фиксированные значения. Т.е. ты проверяешь намертво ли пришиты пуговицы (ошибками в коде) и тебе пофиг на логические ошибки

(300) Т.е вместо того чтобы нанять отдел тестирования мы будем заставлять прогеров, которые работают над своим кусочком и не видят картины в целом писать и проводить тесты? Т.е. пуговицы пришиты намертво

(305) Тесты, которые не выполняются автоматически, нафик не нужны :) А тестировщики нужны, конечно, мы же в реальном, а не идеальном мире живём.

(289) оправдала. Только системы всё сложнее и сложнее, а это уже требует других подходов к разработке

(305) Никакой отдел тестирования (который, btw, проверяет функционал, а не отдельные функции) не поможет. Ибо тогда ПП вообще в прод не выйдет

(304) Исчо один печОнкин...
Логические ошибки НЕ ПРОВЕРЯЮТСЯ юнит-тестированием...

(309) Да, и юнит-тестирование это не TDD :)

(303) объективно я сужу только на уровне стоимости работ, которые, например, делает для меня франч.

(307) что в УТ11 в принципе настролько сложнее чем ТИС что требуетяс какая-то охернность? только СЛАУ?

(311) Так это же не про мелкие локальные франчи речь, а так да, иногда берёшь их код на сопровождение, и не знаешь, толи охреневать, толи плакать :((

(304) это были условные примеры. Нет никакого стандарта, что нужно по 5 проверок на функцию, например. Но так или иначе можно выйти на конечное число проверок, покрывающих наибольшее количество вариантов.
А одна из фишек TDD в том, что она мотивирует писать код более линейно, не делать громоздкие методы с десятью входными параметрами, которые придётся покрывать 100500 тестами, чтобы более-менее проверить. Это уже огромный профит. Помимо того, что код покрыт тестами, такой код легко изменять

(314) А расскажи, кто будет платить за покрытие тестами? И почему они за это захотят платить?

(305) а ты полагаешь, что тестеры смогут более эффективно протестировать тот код, который они не писали и логику которого скорее всего не понимают? Никто не понимает логику кода лучше, чем его автор

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

(315) владелец системы. И тут всё просто, за НЕпокрытие тестами ему придётся платить ещё больше. Намного больше. Ошибка, выявленная на этапе написания кода, стоит копейки, на каждом следующем этапе становится всё дороже и дороже. На этапе промышленной эксплуатации цена ошибки может доходить до тысяч долларов и более. Но даже если ошибка никак не ударит по бизнесу, не вызовет простоев, не навредит репутации, всё равно её исправление обойдётся намного дороже, чем обошлось бы на этапе разработке

(317) разумеется проще

(318) Э... Да вы идеалист-теоретик, батенька.

(320) почему?

(321) Потому, что в (318) это теоретически правильно, а практически не так для 99,9% проектов на 1С в настоящее время.

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

(322) это пока что. Но со временем до 1сной отрасли дойдёт, что гораздо дешевле обрезать ошибки "лишними" тестами на этапе разработки, чем мучительно отлавливать их на этапе эксплуатации. Во взрослом программировании понимание этого давно пришло, скоро и до 1с дойдёт. Всё то же отставание под эгидой "уникального пути"

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

(324) Пока сам вендор не будет так работать, ничего не изменится глобально. И основной вопрос - а оно вендору надо? Что-то не видно пока у них в руководстве свежей крови, как это было в Microsoft.

(311) Необходимость и стоимость - могу дать свой живой пример.
Сейчас мне нужен парсер pdf-файлов. Структура pdf сама по себе дурная и делаю небольшими итерациями: научил парсер читать одни объекты, потом другие и тд
В процессе реализации уже были моменты, что ломал ранее работающий код парсера - где-то токен не обработал, где-то с пропуском whitespace'ов переборщил и спозиционировался не туда.

Вот если бы я делать это все без тестов (юнит в данном случае), то уже бы застрелился.
Но сейчас я могу спокойно поправить код, нажать на F7 и в моменте пронаблюдать качество своей работы. Я даже моргнуть не успею, как узнаю, что новая сборка кривая.
А код, например, такого теста примитивен и в этом его сила:

BOOST_AUTO_TEST_CASE(EmptyPage_details, * boost::unit_test::enabled()) {
    std::string filename(".//test//resources//empty_page.pdf");

    std::unique_ptr<PDFReader> pdfReader = std::make_unique<PDFReader>(filename);
    std::shared_ptr<PDFDoc> pdfDocument = pdfReader->getPDFDocument();

    int major = 0, minor = 0;
    std::string pdfVersion = pdfDocument->getPDFVersion(&major, &minor);

    std::uintmax_t pdfFileSize = pdfDocument->getFileSize();
    int count = pdfDocument->getNumberOfPages();

    BOOST_TEST(pdfVersion == "1.6", "wrong pdf-version gotten");
    BOOST_TEST(major == 1);  // версия.мажор == 1
    BOOST_TEST(minor == 6);  // версия.минор == 6
    BOOST_TEST(pdfFileSize == 4880);  // размер файла 4880
    BOOST_TEST(count == 1);  // должна быть одна страница
}


(327) А при чём тут 1С?

(328) я тут за тесты топлю )

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

https://wonderland.v8.1c.ru/blog/1c-ispolnitel/

(325) к сожалению в ЯП есть условные операторы, которые делают код нелинейным...

могу ошибаться, но пока не видел внятной демонстрации разработки хотя бы тривиального 1С-конфиги "количественный склад с партионкой по ФИФО" с использованием NLL/ чтобы тупо оценить - а печенька стоит выделки?
.
ps^ у меня обычно все "тесты" сводятся к тому, чтобы не допускать на вход алгоритма невалидные входные параметры.

а так да. я бы попрограммировал через ТДД и БДД.
самому начинать трудно без преальной прикладной задачи (даже инструмент освоить), а в падаваны меня никто не возьмет..
так и маюсь по старинке ;-) вроде ничего, норм... ;-) пока...

(331) есть, но не только от них зависит линейность-нелинейность кода, а ещё и от пряморукости прогера. Очень легко сделать код запутанным, с хитровымудренными ветвлениями

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

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

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

(336) "каждая функция была вынесена в отдельный модуль"

https://www.youtube.com/watch?v=l_--ewb4YXg

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

в теме имеет место быть ментальная мастурбация, на языки программирования общего назначения. ну, 1C - не Java, не С++, надо принять это и жить дальше.

Не нужон он ваш этот TDD в 1С.

(339) JUnit всего-лишь пример. А так модульное (юнит) тестирование уже везде и всюду. Даже в сраном древнем COBOLе уже есть юнит-тестирование
https://www.ibm.com/support/knowledgecenter/en/SSQ2R2_9.5.1/com.ibm.etools.rdz.zunit.doc/topics/t_unit_test_cobol_data.html

(340) а что, если 1с не язык общего назначения, то на неё стали действовать какие-то особые принципы в разработке?

(329) Так тут никого нет против тестов в целом, но тема то про 1С :))

(343) Бесполезно объяснять.

Мне кажется что в первую очередь играет культура разработки. Я даже мануальных тестировщика в 1с почти не встречал. Как правило льют сырой код в прод потом уже исправляют баги по мере возникновения. И многих это устраивает как со стороны заказчика так и со стороны разработчика. Такая культура связана с дешевезной сектора 1с. Если компании нужна надёжность высокая доступность сервисов то на 1с вряд-ли будут писать.

(345) да, культура разработки у нашего брата 1сника низка. Но связано это не с дешевизной 1с, а просто с незнанием и неумением. С опозданием до 1с современные методики разработки доходят

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

(347) ХПП? )))

(348) Хуяк, хуяк и в продакшн™

https://cs8.pikabu.ru/images/big_size_comm/2016-03_5/1458912097163946994.jpg

(346) Связываю культуру разработки с ценой ошибки. На 1с в большинстве случаев цена ошибки в коде не достаточно велика что бы хотя бы нанять тестировщика, который по тест плану прийдется и все проверит.
Сам не являюсь фанатом TDD и на мой взгляд сделать интеграционное тестирование сквозного функционала проще. Подняли 1с проинициалтзировали базу файйловую, а дальше создаём к примеру справочник из json/xml и результат обратно в json/xml и сравниваем с эталоном, можно наверное сделать такое через ВЭБ сервисы или АПИ веб клиента

(349) (350) Истину глаголишь!

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

(342) 1C - это предметно-ориентированный язык, он сделан чтобы автоматизировать учет. все остальное допиливается по остаточному принципу.

(354) так не потому что это объективный подход, а потому что "так исторически сложилось". У 1сников пока что низковатая культура разработки

Полезная статья: http://catalog.mista.ru/1c/articles/1056335/

Особенно глава : На что стоит писать Unit-тесты и что это дает
Похоже тут именно об этом спорили пару страниц.

вот открываю я в УНФ диалог выбора типа значения доп.реквизита, поле на форме для задания длины строки - туда можно ввести 1024 (да еще, бть, с пробелом в разделителе разрядов, но это ладно) - тока размер поля такой что видно "1 02" да и двойка наполовину обрезана. Спрашивается - какие пидарасы (в хорошем смысле слова) это делают?!

..возможно это связано с масштабом отображения, настроенном на ноуте 125% (150% тоже частенько бывает, практически норма) - но где тогда гибкость этих гибких экранных форм?! и так, бть, куда ни ткнись - что ни экрначик - то какая-нить жопа...

и какое тестирование такой трабл обнаружит как в (357)?

(355) ну... все в наших руках ))

(359) Как какое? Пользователями, конечно.

(357) Ну это ж не ошибка, так неудобство.

(361) зашибись!

нате вам еще шедевров от пейсателей типовых
(учтите, что я даже в процессы не лезу, все по верхам, по самой тривальности)
https://i.ibb.co/KLHvNNJ/2020-10-07-213649.png

ошибка - ДА! я, блин, инвалид, 2 минуты потратил чтобы набить 15 букв. и получаею зае...ый результат!!!

вот если отвлечьсся от того что ПОЛЬЗОВАТЕЛЬ !!!!_ДОЛЖЕН ЗНАТЬ_!!!
ну ведь логично ожидать раз поле для ввода есть, кнопка есть, значит - должен быть ожидаемый результат - найдено или не найдено.
но блин ну никак не то что на скрине

(358) Ты совершенно прав. На десктопе при 100% всё показывается точно также, как ты описал.

(365) повбывав бы

ты на форум по eya зайди - там всякой такой хрени я понаписал вагон

(367) Почти как форум по ауе прочиталось :) Адрес какой у форума?

https://1cfresh.com/forum/forum/subjlist.jsp?forum=1

А почему бы ещё не писать тесты на функции теста. Вдруг там тоже налажал.
Сам использовал ХХП всю жизнь. Потом попал в большую команду, где тесты были обязательны. Проработав так 4 года, понял, что максимум что они могут проверить это что 2х2=4. Зато времени иногда уходит до 90% на эту хрень.
Если бы заказчики понимали это, они никогда бы не согласились платить за это.

(370) "А почему бы ещё не писать тесты на функции теста." - это я давно задавал то ли здесь в каких-то ветках, то ли в ИС в аналогичных... ;-)

Кстати вот такую хрень как в (364) какойнить тдд/бдд/юнититд - отловит?
причем тест максимально ОТ МЕНЯ независящий. то есть

1. типа "тестируем сценарий полнотекстовый поиск, вводим в строку чтото, нажимаем "искать" - получаем страницу с результатами поиска, если страница не получена = ошибка" - такой тест должен эту хрень отловить.
.
2. но нахера писать такой тест? если блин д.б. тест
"тестируем сценарий полнотекстовый поиск. если GnG = вЫкл - и получается ввод в строку, это - ОШИБКА"...

Вопрос:
какой тест написать - есть правильно: 1 или 2..?
если 2 - это значит при программировании страницы ПтП - кодили полные дебилы (в хорошем смысле слова).
если бы кодили нормальные - то даже теста на такую тривиальную хрень не надо было бы.
.
(задумался про разработку через тестирование)

а это значит - мне как тестировщику - надо блин писать больше и понимать лучше чем эти криворуко-кодеры...
это насколько стоимость разработки/продукта возрастет?
.
нахера таогда всякие ТЗ/ТП и прочая хрень..? сидит команда ХХП, сидит команда тестировщиков (а еще лучше отдать эзверям и назвать это "сценарии прикладного тестирования" ;-) и аджайлит/скрами и канбанит адски... - так что ли?

Прочитал тему. Немного взорвался мозг.
Нет в 1с тестов и не надо их там делать, пусть хоть в одной отрасли программисты нормально пишут с головой. А то если еще и 1сники перестанут норм программировать, то кто будет заниматься автоматизацией?
Пишите сразу без ошибок - так лучше, чем писать непойми как и потом еще 100500 тестов такого же качества.

(373) вот как раз 1сники НЕнормально программируют. Пока мелкие задачи всё хорошо, но чуть дело доходит до сложной задачи, начинается трэш...

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

(373) А ёжиками мышам стать не надо?

(370) а это уже вопрос квалификации. Тесты тоже нужно уметь писать. В вашем случае видимо заказчик нужность и важность тестирования понимал, да прогеры не понимали

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

А вы все полощете
Ню ню

такс. какой тест отловит такую хрень.
УНФ - групповое изменение реквизитов - справочник договоров, Отбор "Контрагент договора в ГРУППЕ ИЗ СПИСКА" - открывается СЗ дл янабора групп (добавить/подбор) - в открывшемся ШТАТНОМ диалоге - нет возможности выбрать группу.
иерархия групп есть - отдельный списочек на форме - но он только для указания элементы какой группы отобразить a форме списка...?

каким тестом это отловить?

(380) BDD

(377) ну так может и программирование - это вопрос квалификации. Код тоже надо уметь писать.
если код не умеют писать нормально, приходится покрывать его тестами. то откуда будут писаться нормальные тесты? не умеют писать коод - внезапно умеют писать тесты? херня-с!

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

в чем цимус этот тест формализовать?

(383) Да, ты должен сделать тест типа "Я открываю групповое изменение реквизитов, выбираю то-то и то-то, щелкаю отбор, выбираю такую-то группу"
Цимус в том, что если какая-то скотина это поломает, то об этом скажет ночной тест, а не наткнувшийся на это пользователь

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

УНФ. Форма списка документов "заказ покупателя" - Еще-Изменить форму - Выключил две галки, включил одну из них - получил ошибку кода.

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

я ЛИЧНО как тетсердолжен перебрать (написать тесты) ВСЕ ВОЗМОЖНЫЕ ВАРИАНТЫ комбинаций всех галок и всех последовательнойтсей манипуляции с ними, чтобы протестировать нормальное поведение формы?

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

(386) теперь просто хрен открыть форму списка заказов. основной инструмент менеджера.
тупо валится в ошибку. я хренею с этих пейсателей типовых продакшенов.

(387) пока я только матюками могу обложить...

(386) Все комбинации никакими
Но твой обнаруженный косяк можно добавить в тест

(384) "Цимус в том, что если какая-то скотина это поломает, то об этом скажет ночной тест, а не наткнувшийся на это пользовате"

То же самое делает юнит-тестирование, только эффективнее. А при TDD скотина, поломавшая функционал, узнает об этом ещё на этапе разработки

(390) зашибись.
я обнаружил косяк.
добавили в тест.
косяк тут же поправили.
В ЧЕМ ЦЕННОСТЬ ТАКОГО ТЕСТА ДАЛЕЕ? в том что вдруг внезапно через полтора года что-то сложится что приведет к слому того что исправленный косяк исправили еще раз и косяк снова всплыл?

(390) хрен с ним со всеми комбинациями.
пусть будут "ключевые" комбинации.
кто будет определять эти ключевые комбинации - Я?!
или может все-таки кодить надо правильно СРАЗУ (похорен как какими инструментами условно пока. главное - правильно).

(391) Да заканчивай уже что ли
TDD это никогда не обнаружит и правильно сделает

кто, бть, должен делать правильно - например если вводится месяц и день что не бывает 30 февраля? я об этом на тестах должен хаботиться или все-таки кодер должен изначально  обрубить такие проблемы при кодинге? а то полувчается - хрен ли думать при кодинге, покроют тестами - где гавно всплывает - тогда и поправим? а сейчас ХХП и норм!
нахрен такой аджайловый/экстремальный подход!!!

что могу сказать из своей практики.
пока что я , с типовой ТиС, с кучей своих "костылей" - работается манагерам лучше и беспроблемнее чем, б! типовая УНФ с кучей ХХП-разрабов... преувеличиваю конечно.. но вот как-то так пока у меня впечатление от типовой УНФ... злой я. злопский. хотел в Добропа переименоватся, хрен! буду Злопом.

(392) В том, что есть вещи, ты не поверишь, которые ломают постоянно

(391) Ты ещё скажи, что на этапе статического тестирования кода поймает, да :))

(392) Кроме того, бывают вещи, которые важно, чтобы они работали
А сломать их можно миллиардом способов

(393) Да, ты

(395) Не не не, ты меня с Конструктором перепутал, это он такое предлагает

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

(394) обнаружит, если тесты писали пряморукие

Две очень разные ситуации:
1. Нажали на кнопку и отработало 100 строк кода
2. Нажали на кнопку и отработало 100000 строк кода

В первом случае Ванессой ещё можно покрыть. Во втором случае Ванесса просто бесполезна. Скорее всего результат будет очень сложный и/или многовариантный. Покрытие BDD будет чрезвычайно мизерным, в лучшем случае отловит ошибки падения программы, т.е. отработает самым банальным образом. В то время как юнит-тесты эти 100 тыщ строк кода могут покрыть от и до

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

(402) я стараюсь грустнеы лица перед руководством не делать. я сижу и как 1сникдятел - ВЫДАЛБЛИВАЮ. и беру за это столько скольо беру. и перед начальством грустныве лица не делаю. долбить много - а денег мало, ну его нахрен такую работу

(403) почему кодеры пишут криво, а тесты кто-то внезапно будет писать прямо?

(404) немного потерялся что такое юнит-тесты

(403) Вся идея тестов завязана на том, что прогеры криворукие
Если они изначально пряморукие, то тесты вообще не нужны
Более того, такая идея никому бы и в голову никогда не пришла

Но да, да
Криворукие епланы пишут код, а пряморукие программисты пишут тесты, ага, все именно так

(408) Это когда ты для функции СложитьДваЧисла(Число1, Число2) пишешь тесты, которые проверят, что
СложитьДваЧисла(1, 1) вернет 2,
СложитьДваЧисла(2, 2) вернет 4,
СложитьДваЧисла(5, 7) вернет 12
и т. д.

Точнее, Конструктор все перепутал нахрен и на самом деле тесты пишутся сначала в качестве ТЗ разработчику, типа нужно разработать функцию СложитьДваЧисла(Число1, Число2), которая:
Для параметров 1 и 1 вернет 2,
Для параметров 2 и 2 вернет 4,
Для параметров 5 и 7 вернет 12
и т. д.
А после реализации функции как раз запускаются тесты и проверяют, не налажал ли разработчик

Но это уже такое, не будем придираться

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

(411) Смотришь в суть
Именно поэтому TDD практически никто и не использует, долго, дорого и бесполезно

(410) ты сам как себе представляешь, чтобы тесты писались в качестве ТЗ? Имена классов и методов с потолка берутся?

(413) Как ты задрал, а
Открой https://ru.wikipedia.org/wiki/Разработка_через_тестирование и читай "сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест" до просветления

(412) вот ты снова нифига не понял. Юнит-тестирование - общепризнанный стандарт в разработке ПО. Им пользуются все, за редким исключением. В 21-м веке ни один серьёзный продукт не пишется без юнит-тестирования, разве что поделки на 1с пишут без юнит-тестов. А TDD это эффективный способ получения тех самых юнит-тестов

+(414) Еще раз, мне абсолютно пофигу, пишется код по тестам как по ТЗ или пишется по отдельно поставленному ТЗ, а тесты запускаются потом
Главное, что я в подавляющем большинстве случаев не вижу практически никакого смысла в тестах, которые будут постоянно проверять, действительно ли функция СложитьДваЧисла(Число1, Число2) возвращает результат сложения двух чисел

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

(417) Я все в (242) написал про целесообразность TDD, но ты, судя по всему, не поймешь

(418) это твоё абсурдное видение ситуации, основанное на НЕпонимании принципов модульного тестирования и принципов TDD. Что-то типа забивания микроскопом гвоздей, ой какой плохой микроскоп...

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

(420) +1

(419) Блин, да прекрати ты модульное тестирование к TDD приравнивать, ну ведь как галимый теоретик выглядишь.

(420) в данном случае разработчик скорее всего не проверит такой кейс мануально. Но как только пишешь тест то сразу рассуждаешь о граничных точках для проверки. При написании тестов почти всегда нахожу баги в своем коде.
(417) TDD не для всех задач подходит, так как нужно видеть архитектуру в целом перед началом написания кода. Там где проверяют разные варианты реализации и выбирают лучший тесты лучше начать писать когда костяк архитектуры заложен.

Какое TDD в 1ц? о чем вы? Опомнитесь, еретики! Мне сегодня прилетела задача. Есть документ, в нем расчёт показателей идет. А задача заключается в том, что бы один реквизит удалить и завязанные на него расчеты переписать без его учета. А это третья часть всех формул документа. Только реквизит этот добавили три месяца и переписали полдокумента под него. Теперь расскажите как вы будете разрабатывать через тесты, если через месяц у вас полностью меняется функционал?

(424) Некогда объяснять! Суй помидоры в жопу!

(424) Зависит от гранулярности тестов.
Для простоты представим примитивный приходный документ с полями "товар", "ко-во" и замудренная логика как этот товар будет распределен по складам.
Допустим входящие параметры описаны в JSON
input: [
  {"товар": "отвертка", "ко-во": 1000}
]

и ожидаемый результат в регистре тоже описан в json
output: [
  {"товар": "отвертка","ко-во": 20, "склад": "главный"}
  {"товар": "отвертка","ко-во": 980, "склад": "не главный"}
]

По сути это и будет описание требований.
Таким образом логика может значительно поменяеться, но правка теста будет не значительной.

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

(422) а я их не приравниваю. Но кроме модульных тестов никакие другие не напишутся во время написания кода...

(424) так как раз в том и суть, что при TDD вместе с кодом меняются и тесты. Кстати, у тебя типичный пример 1сного говнокодерства. М.Фаулер плохие подходы в написании кода называет "запахи". У тебя как раз код с душком. Вот конкретный "запах":

Стрельба дробью
При выполнении любых модификаций приходится вносить множество мелких изменений в большое число классов (в нашем случае пусть будет процедур, хотя даже не уверен, что автор выделил всё это в отдельные процедуры)

(426) тестировать всё до малейшей функции никто не призывает. Некоторые функции могут быть протестированы только в связке с другими

А так, как пример уместности тестов в 1С, можно посмотреть, как сделана библиотека HTTP: https://github.com/vbondarevsky/Connector Хорошая библиотека, кстати, рекомендую.

(427) на счет говнокодерства не спорю, но расскажи как тогда без дроби обойтись когда есть некий коэфициент который в разных формулах используется по разному, например у тебя есть Коэффициент К. И вот у тебя: В=А*К; D = (C+ E)/К; M = (L+H)/P-K. А теперь тебе нужно сделать B тянется из регистра в зависимости от выбранного показателя; D = (C+E);  M = (L+H)/P-N. Как здесь "не стрелять дробью"? "так как раз в том и суть, что при TDD вместе с кодом меняются и тесты" вот поэтому и не подходит разработка через тестирование. Потому что дорого. Сначала ты пишешь тесты, потом код. Потом прилетает изменение и ты переписываешь тесты, потом переписываешь код. И тебе приходится не только код писать но и тесты. а времени нет, потому что у тебя на задачу выделено 4 часа и заказчик платить больше не хочет. На крупных проектах возможно и есть место такому подходу когда ты пишешь самописку. Но когда ты делаешь доработки уровня не больше подсистемы - а большая часть работы 1сников и заключается в мелких доработках типовых конфигураций, - то такой подход неоправданно дорогой.

Крупные проекты - это сколько? от 20 миллионов?

(430) это от функционала)

(431) А я думал, это от количества пользователей :)

От цены ошибки )

что считать крупным функционалом?

(429) "заказчик платить больше не хочет"

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

(429) а не стрелять дробью довольно просто - достаточно освоить принцип инкапсуляции и делать нормальную декомпозицию

(436)  я привел пример, покажи в нем как сделать нормальную декомпозицию.

(437) В начале пишем некий конструктор формул с тестами. Отделяем получение данных от конструирования формул. После этого конструируем нужный набор, мокаем получние данных и пишем тест на каждую формулу.

(435) фигня полная. бизнес заказчика просто не доживет до того как вылезет ошибка.

(437) вводных данных маловато. Но что-то мне подсказывает, что вычисления происходят прямо в запросе. Это такая распространённая болезнь среди 1сников, приводящая к стрельбе дробью. Например, когда ставка НДС поменялась, в одном несчастном перечислении добавилось пару значений, а в коде вносили изменения в 100500 местах. Этого не произошло бы, если бы извлечение данных было отделено от вычислений

(439) смешно. Обычно бизнес вляпывается в первые ошибки только открыв поделие 1сника, ещё несколько ошибок отлавливается в первые дни эксплуатации. Метод ХХП не щадит времени ни заказчика, ни разработчика

И не знаю, о каких узких рамках от бизнеса вы тут пишете. Обычно всё-таки разработчик оценивает трудозатраты и сообщает их бизнесу. Если бизнес выкручивает вам руки, говоря "нефиг заниматься этим 30 часов, сделай за 5 часов к сегодняшнему вечеру", то это минус в вашу же карму профессионала. Программисту виднее, что и как делать. Настоящий профессионал не допустит, чтобы им помыкалы в ущерб качества его работы. Если идти на поводу у бизнеса, то это будет похоже на выкатывания требований пациента перед врачом: операцию делайте не два часа, а максимум час, и не тратьте время на мытьё рук. По-моему такие наставления пациентом врача выглядят совершенно нелепо, не говоря о явном вреде

ТС, а ты сам то пользовался хот-бы xddTestRunner?

(443) нет. Чем он примечателен?

(444) А что ты тогда вообще использовал? xddTestRunner - это вроде как развитие xUnitFor1C, такому фанату тестирования, как ты, стыдно не знать.

(445) я использовал полноценные модульные (юнит) тесты. Не на 1с правда. В 1с платформа не позволяет полноценно выполнять юнит-тесты

(443) скачал, посмотрел. Такая милота... Уже при открытии обработка начинает ругаться на модальность. Ладно, включил в конфигурации модальность (в рабочей базе это не пройдёт, никто ради внешней обработки менять ключевые свойства конфигурации не будет). Едем дальше. Обработка требует каких-то плагинов. Что за плагины удалось выяснить только через отладчик. Автор не удосужился снадбить обработку поясняющими сообщения. Оказывается нужны другие внешние обработки ("плагины"). Загрузил из того же репозитория. Снова обработка xddTestRunner падает в ошибку...

Это что за нафиг? Утилита как бы тестирования, падающая в "красную" ошибку. У меня прям диссонанс...

(447) А вот я скачал, 10 минут почитал документацию, и ничего, кроме самих тестов, никуда не падает. Сдаётся мне, что вы сугубый теоретик.

(441) обычно бизнес вляпывается просто открыв типовую конфигу.
а потом уже 1Сники сие поделие доводят до ума.

(442) Вопрсо: какого МПХ в типовых тогда столько ошибок? там-то кто кому руки выкручивает?

(447) убедился, ть! я писал выше - то есть код пишут кривой. а тесты будут писать прямые? юзай, суко, сабж! ;-) он не только тесты он еще и для тестов и он по определению правильный! это ты тупой! ;-)

(451) Не, ну если документацию не читать и использовать ПО не по назначению - так оно и будет :)

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

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

(450) по сравнению с народными поделиями, концентрация ошибок в типовых ничтожно мала

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

(456) для начала ты меня дезинформировал. Написал про xddTestRunner. А это НЕ самостоятельная обработка

(457) Ну ты это... всегда сначала скачиваешь, а потом начинаешь разбираться, что это и как работает? А ещё что-то тут про тестирование с умным видом рассказывать пытаешься? Ладно, успехов. А я займусь модульным тестированием, как раз задачка на него хорошо ложащаяся в работе.

(456) "никаких там модальностей не надо"

ты заблуждаешься. Код из обработки:

НайденныеФайлы = НайтиФайлы(КаталогПлагинов, "*.epf", Ложь);

чтобы этот код заработал в конфе с отключенными синхронными вызовами, должно использоваться НачатьПоискФайлов(), иначе просто будет выпадать в ошибку "Использование синхронных методов на клиенте запрещено!"

(459) Рукалицо. Ты чего, не понимаешь разницы между синхронностью и модальностью? Ладно, это уже совсем не интересно, всё ясно про тебя.

(458) ты же сам в (443) и написал про xddTestRunner. Я просто не мог знать, что ты меня дезинформируешь

(460) прекрасно понимаю, у меня за спиной около двух месяцев опыта перевода большой конфы на асинхронные и немодальные вызовы (два месяца только этим и занимался). К чему твой этот пафос?

xUnit теперь называется vanessa.
а сам xunit более не поддерживается