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

(0) чё ?

что за зверь

В смысле через тестирование?
Это что разработка проходит цикл анализ-разработка-тестирование-внедрение?

Хорошая вещь. Но не панацея.

типа экстремальное программирование с частотой тестирования 2 юзера в час?

wiki:Разработка_через_тестирование

это типа когда нет внятной задачи, нет абстрактного мышления и нет грамотного разработчика, видимо

(7) как раз наоборот... без внятной постановки теста не написать - и весь этот гимор не будет стоить выеденного яйца

(0) хрень, особенно в условиях наших реалий

очередная "пуля"

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

Хочется Лефмихалыч услышать.  Он чем-то таким заморачивался v8: v8: Экстремальное программирование и 1С. И хочется и колется...

(10) в 8.3 появилось автоматическое тестирование

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

это всё из-за недостатка ООП

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

грубо говоря, сабж тавтологически замыкается в грамотное ООП
для чего нужно ООП? чтобы можно было влёгкую писать компоненты, используя мощь предков, и тестировать их
к чему приводит разработка через тестирование - к появлению ООП

но покамест в 1с нет ни ООП, ни даже жалкого подобия Visual Studio Blend, ни XAML, ни модульности внутри одной типовой конфигурации

а как оттестировать программу тестирования?

(12) Тестировать что параметры печатной формы поменялись местами нет смысла. Про печать сложнее. Можно попробовать печатать в nul.
(17) самотестами

(14) ООП к тестированию - никаким боком не относится.
(15) ООП не нужно
(16) Все это есть, мозг только приложи

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

(19) Вот мне и хочется услышать "бывалых".
Проблема писать тестопригодный код?

TDD само по себе еще тот мазохизм. А в применении к 1С вообще превращается в случку бобра с козлом стоя в гамаке на лыжах

тестирование
тестирование тестирования
тестирование тестирования тестирования
оргазм!

Меня всегда надирает спросить апологетов всякого рода тестирования: если тесты — это тоже код, то надо ли тестировать тесты?

Так же приглашаются pumbaEO и artbear
полюбому есть что сказать)

(23) затролить какого угодно можно))

(20) Вот смотри - берем типовой справочник номенклатура из типовой бухни - сколько тестов тебе надо написать что бы проверить все что проверяется в обработчиках перед записью? Или возьми какое нибудь РКО - сколько тестов ты напишешь для тестирования проведения? я на 34 плюнул ибо затра*ался. Добавь к этому еще что никто тебе тесты не оплатит, никто не оплатит твои затраты на поддержку, никто не выделит тебе штук 50 разных баз что бы ты поддерживал разное состояние объектов. И основное - твои коллеги болт положат на все твои потуги поддерживать тесты в актуальном состоянии. Хотя все начинаться будет классно - собрание, клятвы верности ТDD, обещание думать перед тем как писать. А потом - то времени нет, то желания, то "это же очевидно! зачем тестировать очевидное? " (ну действительно, очевидно же что РТУ двигает регистры, нафига тестировать?)
Резюме - в своих проектах ты можешь для себя применять подобный подход, когда за код ты отвечаешь сам перед собой и Господом Богом, во всех остальных случаях - беги ты от этого. Не нужен в 1С красивый, корректный, логичный код.
(21) К 1С - +100, на лиспе - наоборот нравится.

(24) Ты начни с того что Артем работает больше с С++ где есть своя инфраструктура, а Женя тесты прикрутил больше от отчаянья, нежели по необходимости. Ему свою разработку двигать надо

(23)
Да.
Разработка через тестирование как раз это и подразумевает.
Сначала пишешь тест.
Допустим тест:
a+b = 2
Потом пишешь 100% прохождение теста:
a = 1;
b = 1;
Если тест проходит успешно - отлично, пишем код под тест, если нет, переписываем тест.
В итоге имеем код полностью покрытый тестами.
В 1С туго с тестированием. В основном функциональщина, остальное временами излишне и только мешает.

(28) Предположи что ты тестируешь закрытие месяца.

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

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

(24) Лучше постучись к Артуру в скайп - он тебе много чего расскажет.

(30) знаешь, глядя на типовые именно такое впечатление и возникает.

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

(32) уже общаемся в скайпе. пока думаю как мне его разработку у себя поудобней прикрутить.

(20) Да, в 1С часто проблема писать тестопригодный код.

Кроме того, проблема быстро и качественно писать тесты. В развитых языках не проблема написать тест-фреймворк, который бы отслеживал, к примеру, каждое обращение к несуществующему реквизиту объекта или элементу структуры, и красиво валил тест с логами и диагностикой, а не валил программу. Написать ОДИН РАЗ, заметьте, и потом применять везде. В 1С же -- попробуйте...

Кроме того такой стиль разработки (итерации тест - код, тест - код) не поощряется 1С-овской IDE. Попробуйте так с модулем или формой документа. Если отчеты и обработки могут быть внешними, и это как-то спасает, то документы намертво прибиты к конфигурации БД, и без ее обновления не взлетают. Это сильно тормозит процесс.

Когда это изменится, можно будет вернуться к вопросу.

В группе на LinkedIn человек утверждает, что они работают по TDD, и 100% покрытие кода автотестами.

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

(38) логирование действий пользователей за 1 месяц

(38) Столько, сколько вариантов скидок применяется в компании.

(40) правила могут быть достаточно "дикие", на что у маркетанов мозгов хватит. Типа: "если клиент проработал с нами >5 лет, то скидка N%, но на марки 1,2,3 еще +M%, да скидка на товар Z по акции, причем остальные скидки не суммируются. Но если заказ превысил Y000 уе, то вообще действуют спец.цены." или что-то типа того

(41) это уже область функционального тестирования.
для юнит тетстирования другие рамки, но и там не легче


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

TDD в 1С активно есть и развивается.
Сам юзаю ТДД в 1С более 10 лет.
У нас в компании уже куча народу на тесты подсела :)
Я тесты юзал, и когда фри был, не только на фикси.
ЗЫ а также юзаю в других языках - С++, JScript, PowerShell

TDD - это не только юнит-тесты, и интеграционные, и функциональные/приемочные.
(37) >>В группе на LinkedIn человек утверждает, что они работают по TDD, и 100% покрытие кода автотестами.
Вот это сказка - 100% покрытия кода не бывает и стремление к нему очень пагубно на самом деле.

Ребята, не нужно пытаться покрыть тестами все возможные тестовые сценарии.
Это бесполезно :)
Тестирование никогда не найдет 100% ошибок - это аксиома :(

(43) что вы используете в качестве моков?

(19) По поводу пляски с бубном и выделение отдельной базы под тестирование.
1. Как в любой рутинной работе, ручное тестирование быстро надоедает. В итоге тестирует пользователь и возникает куча проблем с качеством, обратной связью, стабильностью, отзывами и т.п.
Тестирование разработчиком в любом случае нужно и мы должны это делать.
Нужны инструменты автоматизации и увеличения производительности.
И инструменты есть. Всем рекомендую активно развиваемую систему https://github.com/xUnitFor1C/xUnitFor1C
Автоматические тесты, обычное и управляемое приложение, простой интерфейс. Организация ночных сборок и т.п.
2. Для нормального автоматического тестирования не обязательно нужно отдельная тестовая база. Но она очень желательна. Есть несколько стратегий ее организации.

(46) Моки в 1С не слишком нужны :)
По своему опыту скажу, что чаще удобнее и надежнее реализовывать сразу бизнес-тесты, т.н. приемочные тесты, чем пытаться делать чисты юнит-тесты.
Хотя у меня есть проекты, в которых я сделал моки и разрабы реально пользуются и хвалят подобную реализацию.

+(47) По поводу фреймворка https://github.com/xUnitFor1C/xUnitFor1C
Буквально завтра/послезавтра выйдет версию 2.0.0.0 - специально к чемпионату мира готовлю :)
Много изменений -
универсальные тесты (т.н. дымовые тесты) открытия форм метаданных конфигурации (формы новых объектов, формы существующих объектов, формы списков справочников и документов, формы отчетов и обработок с учетом ограничений пользователей)
запуск встроенных тестов из конфигурации, а не только тестов из внешних обработок
и др.

http://s.pikabu.ru/post_img/2013/10/01/7/1380619389_1366097438.jpg

(48) ну вот в (41) я привел ситуацию в качестве бреда.
И как это тестировать?

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

(44) вот https://dl.dropboxusercontent.com/u/66642502/Безымянный.png
Вроде они только планируют это

(53) Конечно, только планируют.
На 1С такой полный объем пока никто не реализовал.
Мы также к этому идем, хотя у нас все пункты выполнены, кроме 100% покрытия тестами (как я говорил, это не нужно и не достичь)

(41) Берешь и тестируешь :)
Как обычно, создаешь исходные данные, описываешь ожидания, пишешь код для выполнения тестового сценария, сравниваешь результаты с ожиданием :)
Все просто.

(52) Что такое "хитропродуманный отчет" ? :)
Приведи примеры (назовем это тест-кейс).

(55) когда у тебя в условии один параметр, то надо минимум два теста: условие выполняется/не выполняется. Когда у тебя два параметра в условии, тестов надо 4, три параметра - 9 тестов. N параметров - n? тестов. И это если условия простые.
Итого - на одну-две строки кода n? тестов.

Это не считая "создаешь исходные данные" - вы же как-т без моков обходитесь?

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

(0) TDD дорого. Тестировать надо на пользователях (с)1С

(59) пользователи особенно любят когда при тестировании на них определяют дату изменения ДБФ файла, не пользуяюсь ДДшником..

(56) премия менеджера по продажам за месяц рассчитыватся по формуле
S*x+D*y+T*z+B*w+C*v
Где S - объем продаж по сделкам менеджера, за вычетом возвратов
D - доходность сделок менеджера
T - если менеджер совмещает функции продакта, объем продаж его товаров
B - объем продаж по выделенным брендам
C - объем продаж по выделенным контрагентам

x, y, z, v, w - коэффициенты, назначаемые индивидуально, причем y зависит от роста S за последние 3 месяца, w - от объема продаж по выделенным брендам.

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

(61)+ в существующей реализации данные отчета собираются двумя запросами, один из которых строк на 300. Теперь расскажите, как это тестировать.

(61) (62) Могу предположить: в тесте создается тестовый набор данных для расчета по всем показателям, коэффициентам, разрезам. Запускается формирование отчета. Результат сравнивается с эталоном.
Если бы это не было так важно, я бы тестировал, чтоб отчет хотя бы не падал)

+(63) сравнивать можно табличные документы - полученный табличный документ сформированный отчетом и заранее подготовленный эталон. Сравнивать через СравнениеФайлов.Сравнить()
Это я пока фантазирую

(55) Как будет выглядеть, к примеру, тестирование алгоритма движения партий? Ведь тут на каждый кейс нужна своя определенная история в базе.

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

(62) Да, еще одна проблема, нехилый процент бизнес логики сидит в тексте запросов.

(63) а вопрос чисто практический. Если завтра придумают еще один параметр для "мотивации" менеджеров, как случайно не сломать то, что есть? Ведь народ такой, что за рупь порвут на куски

(66) У тебя же есть эталон, если что-то сломается, то тест упадет на сравнении с эталоном

(0) в 1с юнит-тесты уже завезли?

(65) В предусловиях кейса будет прописано создание истории

(65) История хранится в макете, при тестировании из макета переносится в базу, и на этих данных тестируется

(68) см (49) есть фреймворк и несколько заготовок

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

(72) >> эталон чего?
Эталон сформированного отчета.

>> Чтобы получить эталон, надо подготовить эталонные данные
Эталонные данные готовятся в макете, это чтоб тест можно было запустить даже в чистой базе. Макет можно подготовить на основе существующих данных.

Перед тестом данные из макета переносятся в регистры. По этим данным формируется отчет. На выходе имеем табличный документ. Сравниваем его с эталоном. Если тест упал, то сравниваем вручную и глазами ищем отличия. Думаю этого достаточно.
Или тебе надо, чтоб конкретную строку в запросе показал?

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

(74) >> подготовка моков на каждый кейс - это задача, сопоставимая с написанием самого отчета
Кто-то писал (не здесь), что на написание тестов уходит 40-50% рабочего времени. Так что это нормально. Если цель 100% покрытие, то придется жить с этим.

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

(75) так я и спросил первым делом у "гуру": как правильно мокать? Гуру сказал, что моки не нужны. Приплыли, короче.
Ну и (23) становится еще более актуальным: если ты половину времени пишешь тесты, то надо ли писать тесты тестов? А сли ты используешь фреймворк для тестирования, то где ошибка: в коде, в тесте, во фреймворке или в платформе?

(76) Зачем тебе мокать для тестирования отчета?
У тебя стандартная задача тестирования - есть исходные данные, выполняется некий тест-кейс (формирование отчета), получается результат (табличный документ).
Этот результат должен соответствовать ожиданиям [например, полностью совпадать с эталонным табличным документов, или выдавать некие сводные числа (итого сумма, количество)]
Вот эту последовательность действий тебе и нужно повторить в тесте.
Где тут мок?

(76) А если ты используешь фреймворк для тестирования, то где ошибка: в коде, в тесте, во фреймворке или в платформе?
Как правило, фреймворк и платформе наименее падучие, т.к. проверяются/тестируются разными людьми.
А вот ошибки в коде или тесте встречаются чаще.
Есть методики, чтобы уменьшить число ошибок.
Например, ТДД :)
Сначала пишем неработающий тест (это важно), убеждаемся, что он написан правильно и не работает. Т.е. если он работает, под него функционал править не нужно.
И только потом под неработающий тест пишется код/функционал, который заставляет тест работать.

(75) ИМХО при создании первых тестов уходит много времени, те самые 50%.
Обычно сложно создать первый тест на функционал, дальше все проще.
Чем больше тестов, тем их легче создавать и тем легче менять свой код, создавать новый код.
ТДД приносит чувство удовлетворения (зеленая полоса рулит), увеличивает скорость разработки - я, например, отладчиком практически не пользуюсь :)

(74)(75) По структуре тестовых объектов.
Если хранить объекты штатной сериализацией через ЗначениеВСтрокуВнутр(), конечно, при изменении структуры метаданных объекта все упадет.
Поэтому такой схемой пользоваться нельзя.
Вариантов несколько
1. Использовать собственные табличные макеты для создании данных.
2. Использовать выгрузку/загрузку через ХМЛ с помощью Конвертацию данных
3. Использовать выгрузку/загрузку через ХМЛ с помощью собственных способов сериализации в хмл.
Вариант 1 (как наиболее простой и читабельный для пользователя) реализован в xUnitFor1C.
Можно в тесте создавать кучу объектов даже без режима отмены транзакции для создания исходных данных тест-кейса, а затем автоматически всю кучу уничтожать после выполнения теста или его падения.
Просто и удобно.
Тестовый макет можно создавать вручную, а можно сгенерить на  базе реальных данных из базы (например, из рабочей)

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

ТестовыеДанные = ПолучитьМакет("ТестовыеДанные");
Эталон = ПолучитьМакет("Эталон");
юТест.СоздатьДанныеПоТабличномуДокументу(ТестовыеДанные);
Отчет = Отчеты.ОченьВажныйОтчет.Создать();
РезультатОтчета = Отчет.СформироватьОтчет();
СравнениеФайлов = Новый СравнениеФайлов;
СравнениеФайлов.ПервыйФайл = "ПутьКСохраненномуЭталону";
СравнениеФайлов.ВторойФайл = "ПутьКСохраненномуРезультатуОтчета";
ОтчетыИдентичны = СравнениеФайлов.Сравнить();
юТест.ПроверитьИстину(ОтчетыИдентичны, "Ожидали, что отчеты будут идентичны");

Как-то так. Сравнение файлов тоже можно во фреймворк засунуть. Т.е. в тесте точно нет ошибок.
А для фреймворка вроде есть самотесты. Они тож простые.

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

Если юзать TDD, то очень важно, чтобы твои юнит-тесты покрывали как можно больше нюансов

Я сейчас по BDD зависаю, кстати. Прикольная штука

(81) Чуть более точный код
--
МакетТестовыеДанные = ПолучитьМакет("ТестовыеДанные");
ТестовыеДанные = юТест.СоздатьДанныеПоТабличномуДокументу(МакетТестовыеДанные);

Эталон = ПолучитьМакет("Эталон");
ВыгрузитьВФайл(Эталон);
.
Отчет = Отчеты.ОченьВажныйОтчет.Создать();
РезультатОтчета = Отчет.СформироватьОтчет();
ВыгрузитьВФайл(РезультатОтчета);
.
ОтчетыИдентичны  = ЮТест.ПроверитьРавенствоФайлов(ПутьКСохраненномуЭталону, ПутьКСохраненномуРезультатуОтчета);
.
юТест.ПроверитьИстину(ОтчетыИдентичны, "Ожидали, что отчеты будут идентичны");
--

ЗЫ напомните, как на Мисте код 1С можно оформить?

(82) Качество продукта, а, значит, и кейсов, всегда важно, независимо от методик.
В чем сила автоматического тестирования - мы каждый раз уменьшаем число ручных тестов, заменяю их на автоматические.
В итоге мы можем больше сделать - написать код или реализовать дополнительные тесты.
>>Если юзать TDD, то очень важно, чтобы твои юнит-тесты покрывали как можно больше нюансов
При использовании ТДД очень много нюансов закрывается.
Если правильно юзать ТДД, то код очень четко делится на блоки, например, хорошо работает модель MVC. Тестируется М (модель) и C (контроллер), а V (вью, представление, ГУИ, форма) тестится вручную (это просто).

(77) отчет - это не вещь в себе, он строится на каких-то данных, причем, эти данные имеют свойство меняться.
Так отчет, построенный на каких данных, я должен сравнить с эталонным?

Т.е. я правильно понимаю.
Берем данные по всем менедерам, рассчитываем в екселе наши показатели

Далее пишем программу которая рассчитывает эти е данные автоматом

И если данные совпали с данными в екселе - то тест пройден?

(84) ЮТест.ПроверитьРавенствоФайлов - это где? в моей версии фреймворка не такого)

>> как на Мисте код 1С можно оформить
Фрагменты программ рекомендуется отделять от основного текста пустыми строками, тогда они будут более точно распознаваться движком форума и раскрашиваться. Если фрагмент достаточно маленький (1-2 строки или не на языке 1С, то его можно отформатировать принудительно, заключив в теги здесь фрагмент)
http://www.forum.mista.ru/about.php

Тогда это какая то пародия, а не метод, ибо в 99% случаях мы и так имеем предварительно рассчитанные данные, т.е. эталон

(86) эталонный отчет строится по тем же тестовым данным

(88) Выпустил релиз 2.0.0.0
ОФ: для загрузки встроенных тестов из конфигурации есть 2 варианта-команды формы "Загрузить тесты из конфигурации" и "Загрузить тесты из конфигурации (Тест_*)"
#133
переименованы заголовки кнопок загрузки тестов и загрузки отдельного тестового набора

Выполнены доработки для выбора отдельных тестов и/или подсистем #135, #134, #133
Запуск тестов из конфигурации
Доработки для запуска тестовых наборов из конфигурации
#132

ОФ: Командная строка загрузки встроенных тестов из конфигурации #136
#144

Тесты открытия управляемых и обычных, толстых форм:
    + Тесты открытия управляемых форм справочников и документов (новые и существующие объекты, формы списков и выбора), отчетов и обработок
    + Тесты открытия обычных, толстых форм справочников и документов (новые и существующие объекты, формы списков и выбора), отчетов и обработок
    тесты открытия форм существующих документов, перезаписанных на текущую дату
    тесты открытия еще не записанных элементов (созданных с нуля и созданных путем копирования)
    в обычном приложении открываются и управляемые формы
    #117
    удалены устаревшие тесты, т.к. сейчас все тесты открытия форм находятся в наборе Тесты/Тесты_ОткрытиеФормКонфигурации.epf
    #129 #123 #130 #118 #117

Тесты запуска сеансов пользователей с ограниченными правами:
    Реализован базовый тест, который
      * создает тестового пользователя с ограниченными правами
      * прогоняет тесты открытия форм в новых, запускаемых сеансах 1C для созданных пользователей (пока как один общий тест);
    сделана заготовка для размножения подобных пользовательских тестов
    добавлен сводный тест для открытия форм конфигурации поочередно для нескольких пользователей;
    #120

Информатор 1.16:
    При использовании описания тестов через Информатор (с помощью ЮТест.ДобавитьПростыеТестыИзОбъекта) возникала ошибка
    #147
    #120

ОФ+УФ: Добавлен вызов внешних инструментов
    1. ГенерацияМакетаДанных_На_БазеРеальныхДанных.epf
    2. ПоказатьГУИД.epf
    для обычной и управляемой формы
    #131

ОФ+УФ: На форму добавлена команда "О проекте" с гиперссылкой на Гитхаб #128

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

Создание тестовых данных:
    Если при создании пользователя был указан неверный режим запуска, то генерится исключение
    При создании пользователя можно указывать доп.поля
        АутентификацияОС - по умолчанию Ложь
           ПользовательОС - по умолчанию ""
           РежимЗапуска - по умолчанию РежимЗапускаКлиентскогоПриложения.Авто
    Для реквизитов составного типа добавлена дополнительная колонка (№8 - ДополнительныйТипЗначения), с помощью которой можно указать конкретный тип значения элемента;
    добавлен поиск реквизитов с типом ПланСчетов;

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

Вместо внешнего обработчика Message (используется в Снегопат-версии xUnitFor1C, а в 1С это имя как обработчик нельзя использовать)
    можно использовать обработчик-процедуру ВывестиСообщение(Парам);

(88) >>ЮТест.ПроверитьРавенствоФайлов - это где? в моей версии фреймворка не такого)

Будет в следующем релизе.
Создал такую задачу https://github.com/xUnitFor1C/xUnitFor1C/issues/148

(85) я в курсе. Я -- Test Automation Team Lead :D

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

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

(90) Ну к примеру Если менеджер выполнил 120% и более, то его премия увеличивается на 3%
Допустим в качестве эталонна мы взяли выполнения 119% и 121%.
Наш отчет показал совпадения с эталонным, но вот беда. В отчета стоит не > = 120%, а просто > 120%

Т.е. физически не возможно руками рассчитать и подготовить весь диапазон данных (выполнения от -0 до 10000%), то в любом случае возможен косяк в алгоритме расчета, которое пропустит тест
(например мы использовали перемнную с максимум 5 символов, и соответственно если % >100.00, то косяк, которые не выявится на малых цифрах)

(87) (89) Если у тебя в эталоне заложены все 100% возможных совпадений, тогда и код/функционал не нужен :)

(96) Совершенно в дырдочку, я тоже пытаюсь к этому свести

(91) пасиб. буду пробовать.

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

(95) Я уже писал, что никакое тестирование не найдет 100% ошибок :( это аксиома.
Все ошибки находить и не нужно, мы же не НАСА :)
По 120% - ситуация с 119 и 121 нормальна с учетом этой аксиомы.
ошибка все равно будет найдена - например, менеджер прибежит.
В этом случае ты к своим тестам на 119 и 121 очень быстро добавляешь тест на 120% и прогоняешь тесты заново. Если тесты упали, значит, в программе действительно есть ошибка и нужно поправить программу.
Но фактически ты сразу должен был написать 3-4 теста - 119, 120, 121, потому что всегда нужно проверять граничные значения, если их (границы) заранее известны.

(95) >> Т.е. в алгоритме моет быть заложена ошибка, особенно на пограничных значениях, которые тест не выявить.

Это -- проблема написания тестов. В идеале, юнит-тесты покрывают какие-то очень простые тесты.

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

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

(99) Ты говорил, что тебе/бизнесу отчет очень важен.
Тогда тебе в любом случае нужно протестить поведение отчета.
Вариантов несколько:
1. ручное тестирование тобой.
2. ручное тестирование пользователями (ты выбрал этот вариант).
3. автоматическое тестирования на базе тестов.

По вариантам 1-2: представь, отчет сложный, разных кейсов 30.
Ты/пользователи проверили этих 30 кейсов, нашли ошибки в 5 кейсах.
Что ты должен сделать: подумать, поправить код и заново протестить эти 30 кейсов, верно?
Т.е. либо тебе, либо пользователям придется еще раз руками все проверять.
А таких итераций наверняка быть не две, не три, а больше, в зависимости от сложности задачи, количества кейсов и твоего опыта :)

30 кейсов -- это еще не много :)

Кстати, для автоматизации считают ROI - Return Of Investments. И чем больше прогонов автотестов, тем больше этот коэффициент. Автоматизация приносит эффект не сразу, а в зависимости от количества прогонов тестов

(101) [Знаиматься непосредственно тестированием должен отдельный человек] - приплыли. Хотите тестов - нанимайте человека.. Да кто ж его даст-то? Вы еще к франчу мне посоветуйте обратиться

(101) Забудьте про юнит-тесты.
Мы говорим про тесты в целом (юнит, приемочные, регрессионные, интеграционные и т.п.)
В 1С очень сложно, а зачастую и ненужно, получить чистый юнит-кейс. Намного важнее сделать приемочный или интеграционный тест.
Почитайте книги "Как тестируют в Гугл" (или как тестируют в Майкрософт). Там разработчики также тесты пишут. И это правильно, и это нормально. Весь мир давно так уже работает.

(105) :)
Уже читал. Года полтора назад

(104) >>Заниматься непосредственно тестированием должен отдельный человек.
Тут (101) однозначно не прав.
Тестированием должны заниматься и разработчики, и аналитики, и спец.тестеры (если они есть).
Только при совместной работе над тестированием будет нормальное качество продукта.
Иначе никак.

(99) так я и задаю комбинацию ... 99%,101%,119%,121%...

(102) как было замечено выше - мы не АЭС. если там какая-то критическая ошибка, я могу и базу на полчасика "уронить". Но мне проще - у меня база нераспределенная и пользователей сотня, терпимо. А вот если с филиалами, да на пару тыщ человек - тогда да :-)

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

(108) Если у тебя в условии есть 120, ты должен проверить минимум 3 варианта - меньше 120, 120, и больше 120
Почему ты пропускаешь середину?

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

Нет, я НЕ говорю, что разработчик не должен тестировать свой код. Я говорю, что это эффективно только до какого-то порога.

Далее, в тестирование надо инвестировать какое-то время стабильно, раз в спринт. Становится целесообразно нанять отдельного человека

(107) Там где я работаю совсем не так.
(109) Это верно. Очень много зависит от Заказчика. У моих Заказчиков очень высока стоимость простоя, поэтому они не жмутся на выделение ресурсов на тестирование

(102) так проблема в том что для автоматизации тестов, нужно  выполнить п.1. и/или 2.
И только полсе выполнения их, ты моешь перейти к п.3., т.е. заложить данные для теста.

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

(109) Работа в 1С - это по большей части сопровождение продукта, а не выпуск совершенно нового функционала.
Если ты часто меняешь один и тот же функционал, то ручное тестирование перестает быть эффективным достаточно быстро.
И здесь лучше переходить  на автотестирование.

Согласен, что нужен баланс и ТДД это не панацея и не всегда нужно применять.

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

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

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

Вообще есть такая методика - сначала тестируем руками, когда надоест/или устанем, начинаем автоматизировать.

Еще один минус — тесты дают ошибочную иллюзию "защищенности": если код покрыт тестами, то он рабочий. Но это точно не так.

(112) >>Для автоматизации тестов, нужно выполнить п.1. и/или 2.
Их можно не выполнять, если есть приемочные критерии.
Или результат 2 становится приемочным критерием, т.е. тем набором критериев, после получения которых задача считается решенной.
Приемочные критерии должны быть всегда (это может быть ТЗ или какое-то другое описание).
Без приемочных критериев нельзя понять, что задача решена.
Очень часто именно из-за их отсутствия или согласованности между бизнесом и командой проекта и возникают проблемы :(

(116) ИМХО, это как проходить тест-драйв ПОСЛЕ покупки машины

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

Т.е. смысл разработки через тестирования - это повторения алгоритма

Т.е. некий черный ящик (например лист екселя с данными за прошлый год) который на выходе выдает нужные данные (например данные о з/п), и нам надо повторить это в программе. Тогда да, мы пишем алгоритм и сравниваем с эталоном
В 99% случаев получаем что наши эталонные данные посчитаны неверно (человеческий фактор + предвзятое отношение)

(117) Этот минус исходит из той самой аксиомы: Никакое тестирование не найдет 100% ошибок.
Но и ручное тестирование не найдет ошибки.
А за качество продукта нужно бороться.

Кстати показательные в этом случае драйвера на видеокарту. Когда разработчики в погоню за папугаемами подгоняют свое ПО под тот или иной тест

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

+ (122) (119) Видишь, ты сам высказал смысл ТДД - именно сначала тест-драйв, а уж потом покупка :)

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

+ (124) "участки легасу-кода" читать как "участки легаси-кода (legacy)"

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

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

(124) ну и что? Чем, по большому счету, плох легаси-код до тех пор, пока мы туда не лезем?

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

(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 возможность открытия форм конфигурации под различными пользователями, и совместно с открытием форм тесты создания или изменения/проведения справочников/документов.
Эти тесты уже помогли нескольким проектам.
Тесты открытия форм достаточно универсальны.
Можно запускать для любого пользователя (админ, не админ) и искать ошибки.
Также есть автотесты создания пользователей с нужным набором прав и автооткрытия форм для него - здесь немного придется допилить макет для описания данных пользователя.