Поделитесь впечатлениями.

(129) Ты не можешь не знать, как будет выглядеть конечный результат.
Ты все равно примерно представляешь, чего ты хочешь достичь своим кодом.
Т.е. приемочные критерии есть всегда, только часто в неформализованном виде.
Если видение конечного результата у заказчика достаточно размыто, можно использовать механизм итераций - мы реализуем для заказчику одну полезную фичу, демонстрируем, заказчик дает обратную связь и понимание цели улучшается как у заказчика, так и у разработчика.
Часто бывает так, что после первой итерации разработка идет совершенно в другом направлении, чем было заявлено в начале :)
Это вообще схемы Agile и гибких технологий.
ТДД здесь удобен тем, что ты не пишешь большой, сложный и конечный тест,а пишешь тест на маленький/небольшой функционал, который можно быстро реализовать и проверить.

(128) Легаси-код плох именно тем, что его менять страшно. Упасть может что угодно, заранее очень сложно сказать, что, где или когда упадет.

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

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

(132) При изменении функционала тесты могут начинать падать. Это нормально.
Нужно понимать, в чем причина падения тестов:
1. что-то поломали.
2. тест устарел и его нужно либо исправить, либо вообще удалить. Скажу по себе - сложно удалять тесты, жалко свой/чужой/накопленный труд, но "скрепя зубы" делать это нужно.

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

(131) легаси-код отличается тем, что обычно он просто есть. А ресурсов и желания покрыть его тестами, отрефакторить, да просто причесать обычно нет. Т.е., "работает - нет рожь" до первого чиха.

(132) "Разницы никто не заметил"
1. Либо эти кейсы встречаются очень редко
2. Либо для пользователя эти баги не критичны
3. либо тех.поддержка никакая и эти баги не чинит, а пользователи уже задолбались о них писать. А в отсутствие обратной связи от поддержки пользователю надоедает писать об одних ошибках.
По-разному бывает.

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

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

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

(138) я там пару багов видел, кстати ))
нужно куда-нибудь сообщать?

(0) я практикую.. и на проектах пытаюсь проталкивать - но понимания практически не нахожу..
Зы.. по другому, собственно, и быть не может..

Тест есть только в сложных расчетных динамических алгоритмах. Там где формул много и когда куча запросов в пакетах. В остальном и без него хорошо получается.

(141) >> но понимания практически не нахожу
Почему?

(0) я практиковал (когда разрабатывал), мне вообще иделология XP нравилась.

(141) сатрап

http://habrahabr.ru/post/225929/

(146) почитал. муть какая-то.

...чувствую себя тупым и отсталым...

(0) Изначально гнилая идея в 1С.
Объясняю: чтобы писать "тесты" в 1с наравне с функционалом, код "тестов" будет занимать 3 к 1 по отношению к коду функционала. И 80% времени разработки.
Все, что зедсь наобсуждали - обсуждение сферического коня.
Все, что нужно - это при разработке максимально:
- встроить обработку ошибок (вопреки методологии 1с)
- придумать и проверить разработку на всевозможных вводных
- детальнейше задокументировать функционал и что-куда вписано кодом.
А тесты в 1с - это игрушки. Меняются исходные данные - нет обработки ошибок - все "тесты" вместе с функционалом идут в лес.

.. что такео "моки"?
и вообще - куча сокращений и "типа умные слова", и ни одного объяснения.
Хоть один кто знает, что за "TDD" и "MVC"?

(92) Вот что это - 1CUnit - можете пояснить? Методология, применение, цели? Для чего вообще затеяно?

(150) Ну, я знаю. И че?

(152) знал бы, писал человеческим языком )

(152) что означают в данном контексте все эти буковки? Зачем они здесь? Какое имеют отношение к разработкам на 1С?

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

(155)"ТС решил, что и с 1С взлетит."
Как "оно" все может взлететь, если в 1С нет никаких встроенных средств тестирования и проверки, подходящих под обсуждаемые? И все надо делать врукопашную. У кого есть время и желание. Причем заплатят только за "20% функционала".

(156) Я не могу держать ответ за ТС :)

Но, кажется, он 1с-юнит запилил

Разработка через тестирование это тот самый рак, что на безрыбье, т.е. в условиях отсутствия вменяемого ТЗ.
Т.е. в рамках отсутствия четких функциональных требований к системе, программист определяет для себя ряд тестов, прохождение которых как бы верифицирует код на состоятельность в данной предметной области.
Т.е. слово "тестирование" тут себя не совсем в своей тарелке чувствует. Эти все юнит-тесты в коде не выявляют баги тогда, когда функционал изменяется под новые требования. Спросите почему? Элементарно! Под изменение функционала надо переписывать юнит-тесты. Короче, онанизм в чистом виде. Очередной руп/экспи и прочее серебрянное непотребство.

(157) xUnitFor1C пилил не ТС.

(155) Автоматическое тестирование в 1С давно можно использовать. Методика ТДД универсальна, ей неважно, в какой среде работать.
Автоматическое тестирование давно доказало свою полезность.

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

(160) Зачем спорить... Теоретики уже для себя решили, что им тестирование не нужно.

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

(160) Согласен. Но хочется же помочь людям повысить свою квалификацию, качество своих продуктов и увеличить свою производительность.

(160) "Народ, расскажите, как вы поймете, что реализованный вами функционал сделан под требования заказчика?"

Паяльником выясняешь что хочет заказчик, а потом сравниваешь это со своей поделкой.


Хотя, если бы 1С-ники применяли автоматическое тестирование, они бы позорно не выпустили релиз ERP, в котором не открывается форма элемента Вида номенклатуры.

(164) >>Хотя, если бы 1С-ники применяли автоматическое тестирование, они бы позорно не выпустили релиз ERP, в котором не открывается форма элемента Вида номенклатуры.
.
Да, 1С периодически этим отличается :( Сталкивался и на 77, и на 8.Х
.
Я в xUnitFor1C специально для проверки выхода изменений, нового релиза конфигураций сделал "дымовые" тесты открытия различных форм конфигурации (элементы справочников, документов, списки, отчеты, обработки) для ОФ и УФ.
На наших проектах после введения автотестирования открытия форм конфигурацию вероятность такого бага стремится к нулю :)

(165) меня сильно интересует наскольо TDD увеличивает трудозатраты на выпуск рабочих вариантов на начальном этапе его применения...? стоит ли этим заморачиваться?

(166) По отзывам до 50% времени. Потом меньше.

(166) Наоборот сокращает общее время. При TDD меняется подход к программированию.

Кстати xUnitFor1C нашел пару багов тестом открытия форм

(169) а автоматизированная проверка конфигураций (от 1С) разве не находит те же ошибки?

(170) хз. Я пока забросил. Как разберусь с вопросом v8: Как программно получить правило поддержки объекта? так продолжу. Пока не до этого. Надо тестирование запускать, а то туго становится, не углядишь за всем и всеми.

(160) >как вы поймете, что реализованный вами функционал сделан под требования заказчика?
хм... я сначала позырю требования в ТЗ и сравню с объективной реальностью, данной мне сначала в коде, потом в тестовой хоне. Далее - отдам поделие БиАй-у, который ТЗ писал, на опытную эксплуатацию.
А как в этом поможет TDD?

(170) неа, оно поведение не проверяет. Оно проверяет оформление

ОФФ:(171) я вот, кстати, третьего дня тем же вопросом задался... пока одно разочарование

(172) Ты после v8: v8: Экстремальное программирование и 1С. И хочется и колется... пришел к чему-нибудь?

(10) это ты лучше artbear и pumbaEO послушай - они TDD, на сколько я понимаю, на практике применяют в промышленных масштабах.

(174) Ну там глазами вроде понятно как и что, надо только придумать как это распарсить. И что конкретно содержится в файле GUID.4

(175) да - к тому, что на 8.0 не взлетит :)

(176) Артур тут уже нормально отметился + в скайпе общаемся по тестам.
xUnitFor1C себе вкрячил с тестом открытия форм. Думаю че дельше с этим делать.

(174) Кстати, свистни, если докапаешься до истины

фух, прочитал. ПО поводу нытья: "а как же мы хитровыпученные слууучаи тестить будем, да как мы закрытие мееесяца" и прочая хунта. Да как напишете, так и будете. Взять, к примеру, ДО КОРП - он наглухо не подлежит "из коробки" ни какому автоматному тестированию, т.к. там овер 146% кода, которому месту в модуле, находится в форме. Но это не всё не аргумент против ТДД. Это вообще не аргумент.
Да, будет код, который в том виде, в котором его выделил из себя программист, ни какими тестами не покрыть - только матом. Это просто означает, что код надо будет писать соответствующим образом и все. Да, проблема с тестом туповых, отраслевых и прочего фуфла от сторонних разработчиков ни куда не девается, но хотя бы свой код можно и пасть правильно, и тестить автоматно - это уже будет здорово и офигенно. Существующая же практика тестирования биаями и прочими пользюками порочна наглухо - любой присутствующий в этой ветке это знает на своем собственном опыте. Даже те, кто говорит: "и как нам это" или "как нам то". Да, тест может содержать ошибки, но именно по этому их должно быть больше одного. А с ручным тестированием ни чего не сделаешь - даже массовые расстрелы или неистовые премирования могут только временно увеличить эффективность. И вы все об этом знаете, господа.

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

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

(181) (182) Мощно задвинул, внушает)

(179) анализировать. Весь то прикол, в автоматизации этих всех проверок и сообщать тревожным звоночком - "барин, все пропало, обмены застопорились, ниче не работает. Кароч, ж полная вертай свои правки обратно. "

моя версия:
http://i.imgur.com/W5nZEpG.jpg

мешает только неготовность IDE к этому. Конфигуратор готов к TDD в той же мере, в какой он готов к коллективной разработке: теоретицски - это лошадь, но практицски - она падает (с)

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

p.s. без снегопата надо придумывать F5, Alt+Ф, 1 и уже автоматом запустилась обработка.

(170) Женя, АПК (Автомат.проверка конфиг-й) вообще не проверяет поведение.
Основная задача тестирования открытия форм - проверка поведения, аналогично тому, как работает у пользователя.

Кстати, кто интересовался как тестировать отчеты?
здесь https://github.com/xDrivenDevelopment/xUnitFor1C
уже есть рабочий пример с тестом отчета на СКД

(181) не получится никак.
Как можно тестить то, чего не знаешь?
Что потребуется завтра?
(188)>>Основная задача тестирования открытия форм
Открываешь форму - работает. Не открывается - не работает. Как тест проверит, открывается форма или нет? Я если я её из кнопки через зад в отчете через обмены открываю?? Откроется??
(161)>>Теоретики уже для себя решили, что им тестирование не нужно
если "теоретик" - я, то сообщение выше - ерунда. Тестиррование НУЖНО. Но 1С всячески этому сопротивляется.
А 1Сникам только этого и нужно - делать меньше, думать меньше.
Внес изменения - проверь ВСЕ. Еще раз ВСЕ. И напоследок ВСЕ. Потом - в продакшн. И еще раз проверь и исправляй по звонкам.
И как тут помогут тесты??
А то "формы открыть" ... Ну так открой вручную ))
У вас что - на все формы всех объектов тесты написаны? А если через "зад" форма открывается?

Тесты-тесты-тесты... херня это все. Я сегодня три часа убил на то, чтобы доказать продажникам, что БП считает НДС в СФ правильно, а не так, как им хочется. Последним и решающим аргументом в споре с их стороны было: "это большой и важный клиент, и у НИХ программа требует, чтобы всегондс сходилось с всего до копейки." (Клиент - это "Ростелеком" на секундочку). И пи.дец

(160)>>расскажите, как вы поймете, что реализованный вами функционал сделан под требования заказчика?
Прочитаю все, что удалось наскрести по ТЗ. Напридумываю всяческих ситуаций вплоть до вторжения инопланетян и появления у них желания воспользоваться нашим новым функционалом.
Проверю. Проверю еще раз. Смешаю данные. Снова проверю. Прикинусь дураком (т.е. пользователем, конечно). Проверю. Добавлю защиту "от дурака". Проверю.
Возьму ситуацию, что все взорвалось, и на вход в обрабтку поступают даже не данные, а мусор. Сделаю обработку ошибок. Проверю обработку ошибок.
Прикинусь пользователем. Сделаю ему рельсу, где необходимо и возможно. Остальное заблокирую или хотя бы предупрежу.
Проверю.
Напишу и объясню, как пользоваться.
Прикину, как лучше исправлять ошибки и чем их проверить.
Подожду звонков с ошибками.
Исправлю.
Проверю.
Снова подожду звонков с ошибками.
Цикл несколько раз.
Сдаю в продакшн.
А вы тут тесты какие-то обсуждаете... Тесты оттестировать даже функционал не могут, потому что непредсказуемо поведение программы в 1С.
А уж будущие изменения и подавно.

(191)>>и у НИХ программа требует
во-во, "программа ТРЕБУЕТ"...
Т.е. хотелки дают пользователи, а требует - ПРОГРАММА. И расшибись хоть с тестами, хоть без тестов, между пользователями и желехобетонром "программа ТРЕУБЕТ"...

*железобетоном. Скалой.

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

Мягкий знак не нужен

(113)>>Работа в 1С - это по большей части сопровождение продукта, а не выпуск совершенно нового функционала.
конечно... только 90% одноэсником в меру способностей именно тем и занимается - что переписывает и перелицовывает типовые "под нужды компании".
А есть "счатливчики", которым задача стоит с нуля конфу написать. Чтоб, типа, и не УПП, но бухгалтерия и склад работали, и менеджеров не забыть.

Кроме того, так никто и не ответил на вопрос: надо ли тестировать тесты?

(182)>>Да, вы в это время не пузо чесать будете, а тесты писать,
ну напишешь ты эти тесты... а через месяц не то, что тесты - функционал уже не нужен. Работал я в такой компании - там писались бесконечные отчеты из месяца в месяц, и бесконечные изменения типовой под них. Даже отдельные конфы забабахали, и то не помогало. Типа, "коньюктура требует постоянно нового".
Обработка ОШИБОК на уровне платформы - и все эти тесты скопом можно выкидывать.
А вот этого самого главного и нет. А одноэсники лентяи.

(195)>>необходимо построить рядом систему на порядок сложнее
TDD-щики, апологеты, этого не понимают - видимо, под "тестами" и прочим "TDD" они понимают что-то другое... ))

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

(195) и это аргумент против ТДД? Нет. Это ты в очередной раз доказал, что разработка ПО - это не строительство, не животноводство, не растениеводство и не все остальное, кроме разработки ПО.

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

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

не... было бы хорошо провести мастер-класс разработки какой-нить простенькой конфы на 2 часа программирования через ТДД - получится как раз рабочий день с ТДД, ответами на вопросы и прочей хренью.
/
возможно ТДД имеет смысл при промышленной разработке. когда есть план, можно покурить, день-два ничего не решают в сроках. то есть когда ИТ занимается РАЗРАБОТКОЙ программного продукта.
/
нихз непонятно...

(205) На ютубе видел примеров + в каких-то блогах. Тока там не 1С. Но тоже понятно. Хотя на 1С было бы привычнее. Я понял, что пока не ТДД хочу. Хочу чтоб в отделе тесты писать хотя бы начали. Потом ТДД.

(198) это называется троллинг)

(205) мы с товарищем проводит такой мастер класс у себя в компании :)
уже 3 тренинга было, в след.среду 4-й будет

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

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

(198) "Тестировать тесты" - в процессе создания теста ты и так  должен проверять. У тебя же есть приемочные критерии, у тебя есть понимание требований задачи, у тебя есть примеры от бизнеса - все это помогает сделать "правильный" тест.
Еще раз: Автотест - это только повторение ручного теста, только его можно запускать повторно когда угодно и сколько угодно раз.

А что реального можно протестировать автоматическими тестами? Есть доводы целесообразности?

(212) 1. Что считаешь нужным, то и тестируешь.
2. Тестировать каждый раз вручную, или тестировать автоматически.

(208) Надо расширять аудиторию. Вебинар, например.

(212) Если подразумевается вопрос "что можно протестировать без ручного создания этих тестов", тогда ответ "мало что можно" :)
Автотесты - это оптимизация и расширение ручных тестов. Если у  вас нет мыслей, что можно протестить вручную, тогда и автотест не сделаете.
Но мы всегда знаем, что можно протестить/проверить, хотя бы что-то простое и элементарное.
.
В продолжении ответа "мало что можно" могу предложить/порекомендовать на своих тестовых баз позапускать тесты открытия всех форм конфигурации( формы списков, элементов, документов, отчетов, обработок и т.д.) в сеансах разных пользователей (админские и ограниченные права).
Формы просто открываются и закрываются штатным образом, без всяких параметров, как будто их открыл пользователь. Работают как обычном приложении, так и управляемом (тонкий и толстый клиент), формы обычные и управляемые.
.
Находятся самые неожиданные ошибки :)
Каждый, кто запустил этот набор тестов, нашел минимум одну проблемную форму.
.
Все это есть в xUnitFor1C https://github.com/xDrivenDevelopment/xUnitFor1C

(215) Каждый, кто запустил этот набор тестов, нашел минимум одну проблемную форму
Подтверждаю)

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

(207) да никакой это не троллинг! Почему апологеты ТДД не допускают наличия ошибок в тесте? Функциональные или интеграционные тесты могут быть весьма нетривиальными.
Как убедиться в том, что тесты тестируют правильно?

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

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

вот внедряю вмс сейчас - ну так точно прогеры там вообще ни о каком тестировании не слышали. чел, через которого проходит работа - вручную что-то отлавливает. а я просто - беру NCL? врубаю обработку и начинаю тыкать подряд во все ШК которые вижу... - вот тут и начинается самое интерсеное ;-).
.
неплохо бы еще фейсы тестировать на внятность надписей/мыслей. иногда такое написано, что ни спервого ни со второг раза не разберешь... - как это покрыть юнит-тестами или как там у вас это правильно?

(221) неплохо бы еще фейсы тестировать на внятность надписей/мыслей. иногда такое написано, что ни спервого ни со второг раза не разберешь... ?
Не совсем понял, но попробую ответить:
Это называется "управление требованиями".
Должен быть первый порог - сначала нормальная анализ, отсекаем бред, понимаем, что реально нужно пользователю.
Важно - что нужно отличается от того, что он хочет! :)
После прохождения анализа уже можно идти дальше, к проектированию и реализации.

(221) Это нормально и верно. Первый этап часто ручное тестирование.
Вот когда его становится много/долго, тогда уже можно думать об автоматизации.
"Тыкаю во все подряд ШК" - сколько раз ты будешь так тыкать?
два раза по 100 тыков/пять по 100 тыков/десять по 100 тыков (уже 1000 тыков) ?
потом тебе надоест и ты либо перестанешь это делать (к сожалению, самый легкий и неправильный путь), либо автоматизируешь эту проверку :)

(218) Ошибки в тестах не исключены. Вот ты вручную все тестируешь? Безошибочно?

(218) гораздо более интересны два других вопроса:
1. почему антагонисты ТДД считают, что его апологеты не допускают наличия ошибок в тесте
2. почему антагонисты ТДД считают, что ручное тестирование (особенно в условиях, когда алгоритмы нетривиальные) гарантирует более качественную и всестороннюю проверку функционала на соответствие требованиям ТЗ, чем автоматные тесты

Вот мне нужно знать, что не запустится у пользователя после типового обновления.
Часто проблемы с отсуствием прав.
И что я должен тестировать?

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

(226) Вручную ты бы это как тестировал?

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