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

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

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

нате вам еще шедевров от пейсателей типовых
(учтите, что я даже в процессы не лезу, все по верхам, по самой тривальности)
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 более не поддерживается