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

Слышал про регрессионное тестирование хоть раз?

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

(1) собственно, давай - рассказывай!
(как космические корабли бороздят просторы Большого театара)
;-)

(1) Если ты полный нуб в тестировании, то почему так пренебрежительно к нему относишься?

(3) Это проверка того что после доработок старое не сломалось.
И вот тут очень неплохо автоматизированное тестирование

(2) Тут дело не в тестировщиках. ИМХО, главное, что дает этот подход - обязательное контрактное программирование и интерфейсы для автотестов. Разработчик и не должен покрыть все баги своим набором тестов с первого прохода. А вот предоставить интерфейсы для прогона автотестов по базе тестов - уже должен. Это позволит ловить каждую багу руками только один раз, потом сажать ее в банк тестов и ловить пулеметом.

Проверка НОВОГО функционала - конечно же отдельная история

(4) я не пренебрежительно! мну - интересно!! но непонятно!!!

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

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

(9) именно так

Не использовал но я так понимаю что тестирование только внутреннею логику покрывает. Ошибки в интерфейсе и сопутствующем коде тестированием не отлавливаются. Или не так?

Или вы про тесты производительности?

вот

(13) не, как раз про тесты функциональности.

Про нормальные интерфейсы - вообще отдельная тема.
разрабатывать приходится самому. Иначе получается фу...

Блаблабла, голословные теории.

(10) ну ты, блин, умный!
Вот есть у меня ТЗ на входе - размером с сто тысяч чего-то - как я ее в эталонную превращу (то есть в результат правильной работы алгоритма)..?

Я так понимаю для поточного тестирования тоже годится когда на написание тестов закладывают время на разработку + N%. Юнит-тесты или как их там

Система контроля качества (те же ОТК) на заводах как-то же работает, а это тоже ресурсы, затраты.

(18) Для авто тестирования время не особо критично. За нгочь всяко проверится такой тест

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

(22) Для упр форм есть сценарное тестировние

есть также какие то наработки от 1сников
https://github.com/xDrivenDevelopment/xUnitFor1C

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

(22) на мой взгляд это нормально. Например, выпускает завод электронную плату. У него есть стенд который тестирует конкретно характеристики этой платы. Далее - плату доработали/переработали. Стенд подходит? Нет. Уповать что нужно его допиливать тоже глупо.

(25) 1 раз конечно нужно самому проверить. Потом когда проверил - 1 запусск по эталонному набору дает эталонный результат

Пример: пишешь списание по фифо. написал для рту, проверил.
создал тест.
Потом дорабюотал функция для документа списание,
для списания заработало. А работает ли все еще для рту?

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

Зачем тестировать. Выгрузил в рабочую, сказал "готово" и пусть юзвери тестируют

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

Пока что получается что все это - так и есть профанация и мракобесие

Собственно голая совалка

(0) когда влом бывает ограничивался синтаксической проверкой... и ничё, как правило всё норм.

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

Но моя пытается просто без ошибок сразу писать ))

Т.е. нафик не нужно тестирование

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

(37) это применяют когда есть большой заказ "сделать им хорошо" = "непонятно что писать"

и через итерации (разработка->тестирование->разработка ....) пытаются добиться от заказчика-пользователей что они хотят и устроит ли их так ))

(38)+ к примеру по задаче в (0)

решается сортировкой тз по 1-й дате и циклом по ней с переносом интервалов в новую тз и подстановкой отсутствующих интервалов

дата1-дата2
дата3-дата4

при переносе дата3-дата4 если дата3-1<>дата2 то вставляем интервал дата2+1-дата3-1

отдаем на тестирование... и выясняем что даты то могут пересекаться к примеру на 1 день )) типа нужно вставлять не дата2+1-дата3-1, а просто дата2-дата3 ))

(39) не, вот как в принципе прикинуть - какие ситуации надо потестить для этой задачи (при условии что интервалы не пересекающиеся)..?

(40) пересечения это 1-е и високосность года это 2-е ))

(41) ну и вообще проверка что там вообще даты и причем корректные )) а не 32 декабря ))

самый лучший тест - лог интерактивных действий юзеров за год...

берем снимок базы на 1 января 2013 года и повторяем все интерактивные действия пользователей за 2013 год....

правда ни один новый релиз типовых не пройдет такой проверки

(43) это точно... много полезного можно узнать..
а интерактивные действия - это вообще песня...
.
внедряем значит ВМС.
как япроверяю ТСДшные обработки - включил экран какой-нить и давай тыкатьво все клавиши подряд и сканировать тупо все что под руку ни попадется... минимум экранов прошли такое тестирование... ;-)

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

(29)
Отличается это формализованностью и повторяемостью.
То есть тут уже не просто твои "думки", как это может работать, которые (твои думки) "к делу не пришьешь", а конкретный набор тестов. Которые можно хоть сто раз запустить и наблюдать зеленые галочки - "прошёл, прошёл, прошёл, поломался". И самое главное, что надо понять - набор тестов - тоже "живой", как и сама программа. То есть не бывает так, написал тест раз и навсегда. Меняется программа - могут меняться и тесты. То есть если какой-то тест после доработки программы "поломался" - это не всегда значит, что ошибка в программе. Возможно, наоборот, тест устарел и требует изменений.

(46)
> Отличается это формализованностью и повторяемостью.
> ...
> Возможно, наоборот, тест устарел и требует изменений.
Т.с. провакационный вопрос: чем это отличается по сути от
> просто твои "думки", как это может работать
?)

(47) разве непонятно? берем толпу "индусов" на кодинг и одного продвинутого спеца на тесты

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

(47)
Тем, что это зафиксировано в материальной форме.
И может быть показано и повторено. Грубо говоря - когда ты мне продаешь свой код, я спрашиваю - "а как ты докажешь, что он рабочий" - у тебя есть нечто более весомое, чем просто "мамой клянусь". Заметь, наличие набора тестов отнюдь не означает, что код безошибочный. Это распространенная ошибка противников TDD, что они думают, что тесты предназначены для написания безошибочного кода. Тесты фиксируют ожидания того, как должен работать код и ситуации, когда он работает правильно.

(49) точно "индусы" )) - "мамой клянусь"

(49)
> Тесты фиксируют ожидания того, как должен работать код
> и ситуации, когда он работает правильно.
т.е. суть - те самые "думки" - от ТЗ до опыта/интуиции/фантазии прога
более того, формально, любое Если таким тестом и является, не ?)
если речь за уровень тестирования (т.е. выше Если, встроенного контроля синтаксиса и т.п.), то всегда (или почти всегда) можно текущий уровень упростить (до того же Если) банально изменив границы рассматриваемой системы )

Если тесты фиксируют ожидания как должен работать код ....
Нафиг такой тест?
Нужны такие тесты которые должны сломать систему
Или нет?
Что пользы от того что тест подтверждает что система работает как задумывалось?
Это же не означает что сиситема может работать неправильно
Задача какая стоит?
Понятно что в разных умловиях могут быть разные задачи
Но грубо если тест показывает что торг12 печатается правильно это еще не означает что менеджер не ухмтрится кайто накосячить и в накладной вместо петрова будет сидоров
Или я все неправильно в корне понимаю?

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

А при внедрении вис столкнулся с другим подходом -обработка на тсд вроде делает что надо но при этом заломать или завести ее в тупик- как два пальца об асвальт

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

Иди я вообще все неправильно понимаю?

Вдогонку
На мои претензии типа фигли вот тут ломается ответ типа а пусть юзверь смотрит куда жмет

(53) права и машина есть?

а фиг ли я вот тут врезался? - смотреть надо куда едешь ))

(54) нету потому сто я не идиот

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

(56) интерфейс всего лишь средство способ задания исходных данных
А дальше работает функционал

(0) Я свои продукты тестируя сам. Причины следующие: архитектор - я, задачу ставлю тоже я, и лучше меня никто не знает, как встать на точку зрения пользователя и отработать бизнес-логику. Причём проблема усугубляется тем, что разработка ведётся не по ТЗ, а по Agile, что тоже требует учёта при тестировании.

(0) В общем случае, не существует доказательства, что программа будет работать.

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

Разговаривал с другом-прогером - он использует тесты.

Когда спросил как можно использовать их в 1С, но не смог ответить.

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

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

(60) +1

Только я скажу почему нельзя применить неинтерактивные автотесты к 1С.

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

Этот факт вызывает у некоторых 1Сников лютый батхерт и они усиленно ищут способы прикрутить плюшки от взрослых систем к своему детскому конструктору.

(52)
>> Но грубо если тест показывает что торг12 печатается правильно это еще не означает
>> что менеджер не ухмтрится кайто накосячить и в накладной вместо петрова будет сидоров

Именно. У тебя есть тест, только показывающий, что торг12 печатается правильно. Не больше. Но и не меньше.
Ты уже не думаешь, а ЗНАЕШЬ, что на данный момент торг12 у тебя печатается правильно.
Мозг человека легко запутывается и обманывается. Вот небольшой пример-аналогия:
http://www.spr.ru/forum_img/55/2012-11/2382208/2952379.jpg
Клетки А и В на самом деле одного цвета, хотя мозг упорно ДУМАЕТ, что А - темнее.
Так вот тест - это как если наложить на эту картинку маску с отверстиями, в которые будут видны только две эти клетки, закрывающая всё остальное.

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

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

А иначе зачем они нужны?

(63) вопрос в экономической эффективности теста. И как охватить все ситуации?

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

Вот реальный случай. Начальник склада сказал переделать алгоритм так "отсортировать накладные по весу и первую накладную отдать Васе, вторую Коле, третью Пете, четвертую Васе и т.д" т.к по его прикидкам у всех будет примерно одинаковый вес. Сделал - провел тест за несколько дней - получается полный разброс у наборщиков.
Переделал по другому ТЗ, потом еще. До тех пор пока мой алгоритм не стал выдавать нормальный результат. Сколько надо было написать обработок для проведения тестов? И не факт, что правильный результат теста окажется верным в реальной работе.

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

(65)
Грубо говоря, первое ТЗ - это и есть тест. Только он делается не автоматом, а ручками и глазками. Ведь тест это что? Описание желаемого результата для определенных входных условиях. И как ты правильно заметил, развитие программы может привести и к замене тестов (ты же переделал ТЗ).
Грубо говоря, набор тестов и становится ТЗ, только в строгом-формальном виде, да еще и автоматически проверяемом. И да, писать тесты не проще, чем писать саму программу.

Все зависит от разрабатываемого функционала.

Где-то достаточно проверить на "работает/не работает"
Где-то приходится эмулировать работу "тупого" пользователя
Где-то приходится писать автоматические тесты, выполняющие некоторую последовательность n-раз, с контролем результата.

А где-то синтаксический контроль ошибок не выдал - значит все ОК )

странная постановка вопроса, хотя бы 1 запуск требуется чтобы посмотреть на свое творение это будет тестированием?

КтоПроФомуКтоПроЕрему + СмешалисьВКучуКониЛюди  )

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

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

Если менеджер выбрал Петрова - Поставил галку "Выводить артикул" - на печать вышел "Сидоров" это однозначно ошибка.

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

(0) не профанация и вполне жизнеспособно, но накладывает серьезные требования на:
1. возможность автоматизации действий самого программиста
2. возможность автоматизации взаимодействия пользователя с графическим интерфейсом, включая автоматизацию сбора фитбэка от интерфеса (или лога, или как хочешь назови)
То есть с текущей платформой реального профита получить тяжело, т.к. она это все автоматизировать не умеет. Конечно есть и снегопат, и запись сценариев в 8.3.5, и ключ командной строки /logui, но это все - три параллельные вселенные, которые в сочетании с наглухо закрытыми для программного доступа исходниками делает задачу ни фига не тривиальной. Например, какой-нибудь ROBOT FRAMEWORK ты использовать не сможешь, тебе надо будет изобретать свое колесо с блэкджеком и потертыми шлюхами, по дороге решая ворох глупых проблем, связанных с непреднаначенностью платформы для коллективной разработки

(69) нет

+(72) хотя умельцы, которые это практикуют, есть. В том плане, что "ну, как практикуют?" - у них есть автотесты для чего-то им важного, они их гоняют, но говорить про 100% покрытия пока рано, т.к. оно не особо хочет покрываться

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

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

+(76) а то, что ты сейчас пишешь, ты и так сам тестишь по дороге овер 9000 раз

(76) Этоя еще в 1 посте написал )))

Представим сферическую ситуацию: у тебя есть документ Реализация, у которого есть какие-то движения по регистрам и печатная форма Торг12 (или 13). Оно работает и все хорошо, но тут появилась необходимость переработать движения. Ты берешь задачу, пишешь код, движения работают так, как надо и для новых документов, и для старых. Ты доволен, заказчик в экстазе от новых движений, все круто и единороги. Накатываешь это на продуктив и на следующее утро узнаешь, что Торг13 в 50% случаев падает с делением на ноль изза твоих вчерашних изменений. Обидно, блин - ты же ПФ-то не трогал. А таких ситуаций 8999 из каждых 9000
А вот будь у тебя в ходе тестирвоания автотест, который просто дает пинка документу, чтобы он сгенерил печатную форму, ты бы еще до сдачи в опытную эксплуатацию заказчику увидел, что новое поведение не совсем укладывается в старые рамки и все поправил.
Вот оно вот для этого всё

(78) под такую формулировку, которую ты там навертел, можно любой ответ подогнуть. Пиши понятно и не будет повторов

(79) а тут есть нюанс... как узнать что печ форма зависит от движений?

(79) эээ а что низзя этот автотест в виде автообезьянки накатать? чтобы тыкала по менюшкам ))

ЗЫ если печатная форма и код вывода зависит от движений документа, а не от данных в документе то это "какой то изврат"

(82) для уф можно

(82) в бухе счет фактуры вроде как то так печатаются

Всегда тестирую, но сильно не извращаюсь.

Мой выбор 3.
У нас был один ярый тестировщик и любитель идеального кода. Очень-то долго не продержался ввиду низкой эффективности работы.

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

Вопрос то вообщем простой
Как узнать набор входных данных покрывающий алгоритм?

или как работать?
Вот написал код
Пишу теперь тест
Что я должен протестировать этим тестом?
Подать на вход те данные на которые расчитан алгоритм и убедиться что выжаются правильные данные?
Или как?

А если я независимый тестировщик?
Как действовать?
Как понять прошел тест или нет?
Какие тесты делать?

.

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

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

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

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

А в 1с таже инструментов для тестов нет, а в примере это не нужно, ну зачем?

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

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

Если ты пытаешься для себя найти пользу-не найдёшь. Эта техника, как и многие другие, предназначена для облегчения коллективной разработки. Тестеры/сотрудники поддержки/ТРП имеют возможность пополнять банк тестов и передать разработчику багу сразу в виде автотеста. Проверять разработчика - не нужно. Автоматизированному проверка повторно один и тот же баг не пропустит.

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

(95) да никак...90% твоего времени будет уходить на написание тестов.

Сложность тестов может превосходить сложность тестируемой программы? Нужно ли писать тесты для тестов? :)

вот сижу думаю какой же тест придумать, чтобы проверить перевод УПП 1.2 на управляемые блокировки... Только перепроведение документов...

И какой результат считать успешным...

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

(60)
>Разговаривал с другом-прогером - он использует тесты.
>Когда спросил как можно использовать их в 1С, но не смог ответить.

Я понимаю твоего друга...
На ноябрьской конференции "Инфостарт" Алексей Лустин делал доклад на тему автоматического тестирования. Его критиковал Дмитрий Шерстобитов: может оказаться, что вручную прокликать будет быстрее и дешевле, чем написать и пройти автоматический тест. Я согласен с Дмитрием: это проблема двух чашек весов, и перевешивает та, что дешевле, а, на мой взгляд, дешевле именно "прокликать". Но!.. Я же примеряю тест под свои нужды, а у меня разработка идёт по Agile. На некоторых проектах, где разработка строится по иным, например, традиционным, принципам, вполне может быть сложиться так, что автоматизированный тест окажется и быстрее, и дешевле. Отсюда простой вывод: при тестировании надо ориентироваться на задачу. ;)

(102)
Человеческий тест надо оплачивать каждый запуск понемногу (P руб), у автотеста дороже разработка (M руб), но каждый запуск - нулевая стоимость. Ну пусть почти нулевая (К руб).
Таким образом, при некотором N выйдем на N * P < M + N * K - то есть автотест станет дешевле. Кроме того, даже при человекотесте задача разработки теста не исчезает, хотя и упрощается. Только к ней еще добавится задача "сторожить сторожей" - никто не застрахован от ошибок "кликальщика" при выполнении тестов - от невнимательности до саботажа.
Поэтому для автотестов в 1С актуальна задача уменьшения величины M.
Что и делается с одной стороны разработчиками платформы, а с другой энтузиастами - Лустин, Аюханов, Сосна и многие другие.

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

(103) Теоретически ты всё правильно посчитал, вот только на практике есть одно "но"... Зачем каждый раз тестировать то, что однажды уже протестировано? Нечего туда лазить! А коли никто не будет лазить, то и повторные тесты не нужны. Тестировать придётся только новую функциональность, а вот тут-то и включается фактор длительности разработки уже совсем другого теста. И с каждым новым тестом вся арифметика (а с нею и экономика) сразу же летит в тартарары.

(104) +1

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

(105) не совсем верно
Результаты теста зависят от входных данных
Поэтому заключение о правильности тестируемого алгоритма можно сделать лишь прогнав алгоритм в тесте по всему возможному массиву входных данных
Что ясен пень представляется непомерной задачей
Поэтому вообщем надо тестировать постоянно
Тогда можно говоритьхоть о каойто квазиправильности алгоритма

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

Возможно я и не прав
И это все написанное бред моего засыпающего разума
Спецы поправят
Потестируют так сказать в ручном режиме мну

(108) есть методики тестирования в белую(зная всю задекларированную функциональность и часто имея доступ к исходникам) и в чёрную... не справедливо утверждать что один тип методики принципиально во всём лучше другого...

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

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

То есть если утрировать то про всякое это тестирование\автотестирование можно сказать так:
- с драной овцы хоть шерсти клок.

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

Потому что именно ошибки - основная причина недовольства конечного потребителя. А я - кодер, это мой хлеб.

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

(111)
>Сначала стараюсь "войти в режим пользователя",
>то есть тупо жмакаю куда попало и делаю что попало.

Любопытное у тебя мнение относительно пользователей... Видимо, следующий шаг: они тупые, а я один умный.

>Естественно, тщательность тестирования зависит от требовательности заказчика.
>Ну и, кончено, от наличия оплаченного времени.

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

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

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

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

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

(114)
Вот для этого в том числе и требуется тестирование.

(115) Я хотел сказать, что пользователи не "жмакают, куда попало" и не "делают, что попало". Соответственно, твоё тестирование в виде "жмаканья" - бессмысленно: ты (а) не решаешь задачу пользователя, и (б) тратишь своё время впустую.

Есть тестировщики, и весьма хорошие

117
Едрид-мадрид
От того что юзвери не тыкают куда попало не значит что внезапно они это не сделают по какойлибо причине
А мне принципиально не хочется в отпуске срываться и трать полдня чтобы устранить последствия краха
И это хорошо если крах видно сразу и все стало колом
У меня был случай когда аналогичная дырка привела к тому что внешне все ок а внутрях каша полная и это успело набежать за полдня всего
Я дня три потратил пока все это выкусил без остановки процесса

Мой опыт показывает одно
Если есть шанс накосячить то накосячат обязательно рано или поздно

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

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

Другое дело что такому стресстесту подтвергается весьма малое колво продукта
Ибо ресурсоемко и дорого получается
В таком режиме писать можно когда нечего делать больше

(121)
>от того что используется правило коридора никак не следует что это правило корретно запрграммлено

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

>Ибо ресурсоемко и дорого получается

Я именно об этом и толкую! Если будет НЕресурсоемкий и НЕдорогой тест, то и проблемы не будет. :)

(122) А кто будет сам корридор тестировать?
Или грамотный кодер по умолчанию дает код который не нужно тестировать?
Тогда вообще о чем говорить в этой ветке?

>Это уже совсем другая проблема, которая называется "защита от дурака". Для её купирования используется правило коридора, которое программно запрещает ситуации, потенциально могущие вызвать аборт или некорректную, с точки зрения бизнес-логики, ситуацию.

гыгы

такое "правило" вырубало движки истребителей над мертвым морем - там высота ниже уровня океана...

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

fools happen ^-)

Еще не все прочел, но однозначно п.1 "тестирую и пишу тесты постоянно"
с небольшим дополнением - не все нужно тестировать

Еще не все прочел, но однозначно п.1 "тестирую и пишу тесты постоянно"
с небольшим дополнением - не все нужно тестировать.
Дубль

(0) Сценарное тестирование не рекомендую.
Рекомендую наш продукт
https://github.com/xDrivenDevelopment/xUnitFor1C
Тесты пишешь вручную, но данные для них можешь генерить из боевых данных.
Просто и удобно.
А уже потом запускаешь ночную сборку и непрерывную интеграцию и наслаждаешься :)

(0) Странные вопросы.
Это примерно как полноценное проектное внедрение, когда есть описание "как есть", "как должно быть", полноценное техническое задание (ТЗ) и план реализации ТЗ, сравнивать с т.н. технологией быстрого результата, когда есть только примерное видение как должно быть (хотелки пользователей) и допиливания функционала происходит на живом пациенте с оценкой результатов на ходу.

Так и тут. Если есть полноценное ТЗ, то в нём обязательно должно быть описание требований, предъявляемых к системе, и ожидаемое поведение в конкретных обстоятельствах (при каких входных данные какой должен быть результат). То есть набор неких тестов уже заложен в самом ТЗ.
Если ТЗ нет или оно написано кратко (рамочно), то объем и глубина тестирование остаётся на откуп разработчику и  в зависимости от наличия времени и возможностей может быть проведено от чисто символического - просто запустить и проверить, что не валятся критические ошибки, и заканчивая тщательнейшим тестированием с использованием каких-нибудь инструментов типа (129) или типовых от 1С на самых разных входящих данных, в самых разных режимах, под самыми разными правами.

PS Протестировать всё на все 100% невозможно. Иногда в саму логику бывает заложена бомба, которая может сработать при определенном стечении обстоятельств.

PPS >> ...используется правило коридора...
Часто находятся пользователи достаточно грамотные, способные обойти очень многие правила коридоров, чтобы выйти за их границы. Всего не предусмотришь :(

Разрабатываю через тестирование с лета 2014.
Использую
https://github.com/xDrivenDevelopment/xUnitFor1C

Тесты хранятся в Git, разложенные на исходники.

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

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

Вот правильный линк:
https://github.com/xDrivenDevelopment/xUnitFor1C

Коллеги
Я бы за
Но дайте блин общепринятый инструмент для разработки через тестирование
Потому что все таки моя задача как программера выдавать рабочий код
А не разбираться в тоннах софта и всяких прделках

До тех пор пока не будет стандартизирован процесс тестирования пусть даже в отдельно взятой области то бишь у нас одинэсников то это все сракобесие всеравно

тьфу сорри
Сракобесие=мракобесие

Фаны авто-тестирования (не 1с):
https://olegon.ru/showthread.php?t=18538

(133) Что такое "общепринятый софт" ?
Мы тебе дали уже дали ссылки на наш продукт xUnitFor1C. 3 или 4 человека в разное время в этой ветке :)
Я юзаю юнит-тесты свыше 10 лет.
На восьмерке xUnitFor1C работает более 2-х лет, поддерживает кучу возможностей. А раньше юзались другие программы.

Можешь в гости к нам в Связной приехать, покажу примеры работы с тестами, получение результатов, ночные сборки, непрерывную интеграцию :)
ЗЫ кстати, ко всем относится :)
Пишите на мыло [email protected]

(0) Мы и вырабатываем этот стандарт разработки/тестирования  для использования в 1С-разработке, чтобы процесс разработки в 1С был схож с лучшими мировыми практиками.
.
на днях на хабре был интересный перевод по тестированию http://habrahabr.ru/company/luxoft/blog/248051/

(136) А вы там невозможность протестировать метод с транзакцией уже побороли? =)

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

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

(138) Подробнее напиши об этой ошибке.
Лучше приведи пример кода и проверяющего теста.

Вот мой тест на эту тему. Ничего не падает :)


//{ основная процедура для юнит-тестирования xUnitFor1C
Перем ЮТест;

Функция ПолучитьСписокТестов(ЮнитТестирование) Экспорт
    
    ЮТест = ЮнитТестирование;
    
    ВсеТесты = Новый Массив;

    ВсеТесты.Добавить("ТестДолжен_ПроверитьВхождениеДатыВПериод");

    Возврат ВсеТесты;
    
КонецФункции

Процедура ПередЗапускомТеста()
    НачатьТранзакцию();
КонецПроцедуры

Процедура ПослеЗапускаТеста()
    Если ТранзакцияАктивна() Тогда
        ОтменитьТранзакцию();
    КонецЕсли;
КонецПроцедуры

//}

//{ блок юнит-тестов - сами тесты

Процедура ТестДолжен_ПроверитьВхождениеДатыВПериод() Экспорт
        НачатьТранзакцию();    
    Попытка
        
        ВызватьИсключение 1;
    Исключение
        Сообщить(ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()));
    КонецПопытки;
    Если ТранзакцияАктивна() Тогда
        ОтменитьТранзакцию();
    КонецЕсли;
    
    //НачатьТранзакцию();
    ВызватьИсключение 2;
КонецПроцедуры


Жду твой код.

ЗЫ Фирма 1С идет, как всегда, своим путем, но в курсе про нашу работу.
А мы делаем свою работу, приближая разработку к мировым практикам разработки!

(139) Артур, мое уважение, но xUnitFor1C далеко до промышленного стандарта.

+140 мне чтобы написать ФТ пришлось вспотеть, образно говоря.
Подготовка данных из mxl, потом их использование через именованные переменные серьезно тормозит процесс. Надо бы это направление оптимизивароть :)
Ну и есть ошибки в самом движке, все собирался написать багрепорт, но времени не было.

"к нам в Связной" - в Мск?

(140) Конечно, до стандарта очень далеко, но ведь стараемся сделать стандартную вещь, с удобством использования, документацией, примерами, достижением целей тестирования и т.п.
(141) Ага, это тем, кто в Мск и возле Мск проживает.
ошибки я люблю, про ошибки напиши.
.
Пока такая подготовка данных для тестов это самый быстрый вариант. У типового сценарного тестирования 1С ИМХО такого и близко нет :)
Если у тебя есть предложения по оптимизации, с удовольствием пообщаюсь.
ЗЫ у тебя гугл-аккаунт есть? можно в Hangouts пообщаться. Мое мыло выше.

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

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

(142) да мы на гугл+ зафрендены.

ps: вакухи у вас приятные :)

(136) Запилите статью на хабре - почитаем... Приехать в Связной - просто так вряд ли кто поедет. У вас же не семинар. И работа и у вас и "у нас"...

(143) да мне простейшие не нужны были, сами тесты вопросов не вызывали. Мне в срочном порядке нужен был фреймворк для написания ФТ, чтобы протестить сложный функционал на основе определенных данных.
Задачу решил, но вот "в срочном порядке" пострадало по вышеописанным причинам :)

Продукт для ЮТ вполне сносно подходит.

(146) написал ФТ с помощью нашего фреймворка, верно?
Попробуй разложить свои временные затраты при создании тестов по примеру в (143)

(147) львинная часть времени ушла на исследование инструментов и фикс багов, потом на подготовку данных (мне нужны были переменные). Важный момент: у меня было под УФ, и продукт только вступил на эту тропу, судя по коду и комментам к нему :)

Где-то за 4 часа написал 5 тестов для этой ситуации.

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

Разработка через написание тестов увеличивает время разработки в пару раз?

(148) Тестирование в УФ уже пару лет работает. Не так давно дорабатывали для УФ Такси 8.3, были определенные проблемы, решили не сразу.

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

Старая тема по тестированию
v8: v8: Разработка через тестирование и просто автоматическое тестирование. Кто практикует?
Где я уже отвечал на подобные вопросы :)

(151) А сами тесты, они конечно неким волшебным образом отдадки не требуют. И сопроводения тоже. Ага-ага ...
Ну не бывает чудес - код разработанный с помощью TDD конечно более качественный, но он и более дорогой. В добавок, мы тут все делаем очень много "одноразового" по факту кода - заказчик что-то там захотел, это самое "что-то там" получил, но по тем или иным причинам пользоваться регулярно не стал или скоро бросил, или использует, но на 5% ... А преимущества TDD проявляются при длительной поддержке и развитии продукта.
В общем TDD вещь полезная (при определенных условиях), а вот фанатизм по ее поводу - вреден.

(153) Мы говорим о боевых системах, в которых пользователи работают годами.
Так что 1С в любом случае = длительная поддержка и развитие.

фанатизм всегда вреден, никто не говорит, что только ТДД юзать, на любой функционал нужен тест, нужно 100% покрытие кода :)

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

(154) Я в (137) дал пример статьи
>>на днях на хабре был интересный перевод по тестированию http://habrahabr.ru/company/luxoft/blog/248051/
там как раз говорится об ускорении разработки, в т.ч и по Agile, и какое место здесь занимают тесты и их разработка.

(139) Т-щ менеджер, ты там из моей презентации в (138) самое интересное зачем-то выбросил – обращение к базе. А при обращении к базе картинка несколько изменяется. Все четко по рекомендациям:

Процедура ПередЗапускомТеста() Экспорт
    
    НачатьТранзакцию();

    // Создаем много чего для теста
    СоздатьИсходныеДанные();

КонецПроцедуры

Процедура ПослеЗапускаТеста() Экспорт
    
    // Очищаем много чего для выполнение требования независимости тестов
    Если ТранзакцияАктивна() Тогда
        ОтменитьТранзакцию();
    КонецЕсли;
    
КонецПроцедуры

Процедура Тест_Транзакция() Экспорт
    
    // Вызов метода, опирающегося на созданные для теста данные
    ОписаниеОшибки = Неопределено;
    Результат = ДанныеОбработаны(ОписаниеОшибки);
    
    // Контроль
    
    // Должен вернуться отказ
    юТест.Проверить(Результат = Ложь, "Неожиданное успешное завершение");
    
    // Элемент в базе не должен быть создан
    Ссылка = Справочники.Валюты.НайтиПоНаименованию("EUR");
    юТест.Проверить(Ссылка.Пустая(), "Неожиданно создан элемент");
    
КонецПроцедуры

Процедура СоздатьИсходныеДанные()
    
    // Здесь в базу много чего пишется
    
КонецПроцедуры

Функция ДанныеОбработаны(ОписаниеОшибки)
    
    Результат = Истина;
    
    НоваяВалюта = Справочники.Валюты.СоздатьЭлемент();
    НоваяВалюта.Наименование = "EUR";
    
    НачатьТранзакцию();
    Попытка
        НоваяВалюта.Записать();
        ВызватьИсключение 1;
    Исключение
        ОписаниеОшибки = ПодробноеПредставлениеОшибки( ИнформацияОбОшибке() );
        Результат = Ложь;
    КонецПопытки;
    
    Если Результат Тогда
        ЗафиксироватьТранзакцию();
    Иначе
        ОтменитьТранзакцию();
    КонецЕсли;
    
    Возврат Результат;
КонецФункции


Это, вообще говоря, не ошибка – это пример того, что ваши постулаты типа "Тесты должны быть независимы", в 1С слабовыполнимы
Для обеспечения этой независимости вы настойчиво предлагаете использовать транзакцию. При этом получаем отличие среды исполнения теста от продакшна - ровно на эту транзакцию, которая влияет на поведение окружения (внезапно для мировых стандартов, но вполне документировано для 1С).
Вообще интересно, что ж вы там у себя такое тестируете по высоким мировым стандартам, что подобный случай не встречали. ОбщегоНазначения.РазложитьСтрокуВМассивПодcтрок ? =) А если встречали, почему не описали в документации как особенность и не дали рекомендации?
Да, я могу вручную написать в тесте костыль, обходящий эту особенность и стирающий данные. Но я не буду этого делать, потому что написание тестов тогда превращается в написание движка, причем своего, особенного для каждого тестируемого метода. Зачем тогда мне ваш инструмент? Запускалка обработок? Ну дык и позиционируйте ее так, зачем неработающую идеологию-то проповедовать?

(136) А фигли бы вам не организовать очный семинар-встречу-тренинг.
даже плптно (разумно). я бы с удовольствием приехал обогатиться знаниями.
только интересует не примерно вот это https://github.com/xDrivenDevelopment/xUnitFor1C
а все таки для чайников - потому как спецы во всем сами разберутся.
А хорошо бы ло бы например с чего начать? чем должен владет ДЕВЕЛОПЕР (потому что программистов тут среди нас мизер), чтобы начать использовать ваш подход. какой инструментарий нужен? какой софт? типовой сценарий разворачивания и установки для начала использования. Демо-сценарии разработки простенького теста и прогона его.
Мне вот нифига непонятно (я наверное тупой вусмерть). Выделить тучу времени чтобы самому разобраться в ТРЕБУЕМОМ ОКРУЖЕНИИ для выполнения тестов - вообще не понимаю с чего начать.
вот хотя бы взять 1с++ - там была дока где от практически самых начал разжевывалось основы и тривиальные примеры. Хотелось бы вот примерно такое же. чтобы посидев, послушав, посмотрев - приехал домой, скачал нужный софт (?), установил (?), организовал рабочее окружение (?) и начал "писать" тесты, а не тратить неделю на создание пространства рабочего. Пусть тесты кривые будут - это вопрос наработки.
А инструментарий - ну не глубокий я мегапрограммер (еще куча задач кроме программинга) - все что хочется (пусть даже с увеличением первоначальных затрат) - улучшить качество выдаваемых решений и как-то "стандартизировать" процесс создания их.

как то вот так.
сорри, если что-то не так..

(157) по этой теме уже давно проводятся тренинги и семинары.
Например вот:
http://silverbulleters.timepad.ru/event/130489/

Да не существует его, требуемого окружения. Есть наборы говна и палок разной степени паршивости, начиная от 1Сного сценарного тестирования, через яркий пример - продавливаемый Артуром вот этот вот фреймверк и до поделий безвестных криворуких мастеров. Каждый набор интерпретирует Истину Тестирования по-своему. Модульным тестированием обычно страдают фикси, которые и не подозревают, что в одной конфигурации может быть код разных поставщиков. Сценарным – франчайзи, которым главное – внедрить процесс, а потом убрать все шероховатости. Оно и понятно – это отражение насущных проблем разработчиков.
Потому что не ложатся подходы из умных книжек, рассчитаных на сборку кода из исходников и работу с чистыми базами данных на механику 1С с ее вывертами. 1С она другая – не лучше, не хуже, просто другая. Она позволяет разработчику мыслить бизнес-процессами, проваливаясь в код по минимуму. Но в большинстве своем 1Сник не хочет думать о предметной области, он хочет плескаться в песочнице, размышлять над префиксами имен, переменных, устраивать в комментариях переписку о том, кто последний изменял код.  Потому что ему кажется, что это приближает его к “мировым стандартам ”

(156) Так а в чём собственно проблема с дополнительной транзакцией?
Её никто не навязывает. Никаких стандартов, что её обязательно надо использовать - тоже нет.
Просто часто с ней бывает удобней. Вот и всё. Если она в данном тесте мешает - просто ненужно её делать )))

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

А по уму, надо создать запись здесь с описанием проблемы (для начала поискав в уже решенных):
https://github.com/xDrivenDevelopment/xUnitFor1C/issues
Там люди опытные, подскажут как лучше сделать.

(160) То есть постулаты о независимости тестов, не такие уж и постулаты, а уже рекомендации?

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

(158) учтем
Хорошо бы анонсы мероприятий  публиковать на мисте

(158) И что, там реально за 62 бакса можно скачать полную видеозапись?

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

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

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

(158) правильная ссылка http://www.silverbulleters.org/premium-kontent-kursov/
(162) были анонсы - даже банер платный крутился на мисте.

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

Вам пока РАНО разрабатывать через тестирование, надо начинать с малого.

1. установить сервер сборок - любой который понравится через Далее - Далее - Далее
2. сделайте на сервере сборок 3 шага:
а. полный ночной синтаксический контроль текущей версии из хранилища
б. выгрузку исходников в git репозиторий (подключите его к TFS, Jira, Redmine
в. отсылку на e-mail информации

Большего на первом этапе НЕ надо.

Захотите запускаться - [email protected] пишите и Вам ответят.
Также есть специальный раздел форума http://xdd.silverbulleters.org/t/how-to-xdrivendevelopment-kak-ispolzovat-i-kak-rabotat/46

P.S. И как Артур правильно заметил, "Серебряная Пуля" еще в апреле прошлого года после AgileDays2014 произвела небольшую презентацию для 1С о способах/сценариях разработки через тесты. В перспективе наши наработки я думаю будут включены в стандарт в каком-либо виде (никуда не денемся).

Что касается бизнес-задачи я уже писал, что после внедрения наблюдаются следующий финансовые улучшения, для ИТ руководителей

* уменьшение срока возврата инвестиций в 1С продукты на 6%
* повышение уровня утилизации ресурсов инфраструктуры для 1С на 30% относительно текущего
* увеличение индекса удовлетворенности пользователей NPS на 30%
* увеличение индекса соблюдения сроков соглашения об уровне услуг SLA на 30%
* уменьшение срока выхода функциональности в 2 раза
* возможность управлять портфелем продуктов 1С в среднесрочной и долгосрочной перспективе (от полугода до 3-ех лет)

(165) "возможность управлять портфелем продуктов 1С в среднесрочной и долгосрочной перспективе" - и почему когда я читаю такие заявления вспоминается история "про кактусы и розы"?

(165) Вот ты сейчас практически всем заинтересованность и убил, молодец, чо...

Поняли, котаны? Рано вам еще, странные вы. У нас тут финансовые улучшения, для ИТ руководителей...

И да, 62 бакса за курс.

(166) потому что мы с Вами читали одни и теже статьи, единственный способ объяснить пользу от http://scaledagileframework.com/ - использовать именно такие формулировки

(167) не хитрите пожалуйста, как Вы еще обоснуете переход на подобные подходы перед руководством. А специально для Вас мы накидали другое:

Разработчик сможет:
* повысить заработную плату
* повысить процент интересных задач в общей массе рутины
* поехать вовремя в отпуск
* не заниматься микроменеджментом
* не "тушить пожары"
* иметь команду проффесионалов
* выступить на Инфостарте как докладчик
* получить почет и уважение
...
* "мир во всем мире"

(0) что касается самого фреймворка - то да: пока это инструмент от проффессионалов, для проффесионалов. Чтобы придать ему маркетинговой привлекательности и "продуктового" лоска и запущена концепция консалтинга. Продукт то напоминаю OpenSource - то есть Вы можете сколько угодно критиковать на словах, но pull request'ов мы от Вас не наблюдаем, также как и Issue на github. А это говорит о том, что Вы хотите получить НИЧЕГО не отдавай.

В связи с чем я и написал, что по большому счету Вам не нужна "разработка через тестирование". Вы пока не столкнулись с проблемой.

А вот проблемы как правильно написал orefkov - простые и банальные: например когда все только начиналось, среднее количество дней жизни задачи было 112 дней (как раз на проекте PrMex) сейчас по моим данным - это уже 43 дня от момента возникновения до финального аудита выполнения. Вот вам и экономическая эффективность.

(169) "что Вы хотите получить ВСЁ, НИЧЕГО не отдавая" - вот так будет правильней.

(168) У вас забавный промах в оценке целевой аудитории.

Если пристально почитать ветку с начала, то станет ясно, что начали общаться разработчики с разработчиками, на уровне разработчиков. Потом пришел Артур, который начал мягко продвигать свой продукт - ну на безрыбье и то хлеб.
С точки зрения разработчиков.

И тут приходит т-щ помощник Солнца, думая что тут засели как минимум начальники IT служб, и прямо заявляет, что это все для профессионалов, а вам это не надо, потому что экономическая эффективность, и вообще вы негодяи, которые хотят ВСЕГО!

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

И зачем, спрашивается, приходил?

(171) у меня нет промаха в оценке целевой аудитории - я все прекрасно понимаю.

исходный посыл - "профанация и мракобесие". Нет.

Если совсем вдаваться в историю, то продукт Артура, а точнее продукт со множеством участников https://github.com/xDrivenDevelopment/xUnitFor1C/network/members был ответом на попытку в одной крупной компании выпилить 1С в принципе и заменить ее на "кошерную" платформу.

Потом все было еще веселей - как я уже написал: Agile начал рапространяться как "протечка с потолка", и необходимо было реагировать - так возник остальной инструментарий git, code review и всё остальное.

Теперь еще страшней - переход на концепцию DevOps: когда больше нет разработчиков или тестировщиков - есть только инженеры. Так возникли адаптации docker и chef к 1С.

Нам к сожалению или к счастью приходится жить НЕ в закрытом мире 1С, а в тесном сотрудничестве с С#, Java, Ruby, Python.

Если у вас НЕТ подобных проблем - то тогда всякие эти новомодные TDD|BDD не для Вас, пока материнская компания не запилит их адаптацию официально.

И еще в качестве расширения кругозора - найдите знакомое лицо в мире 1С на следующей картинке http://skilltrek.ru/img/02.jpg

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

Могу ошибатся

Хз
Непонятно
Видно нет у меня задач такого масштаба чтобы все это "мракобесие" стало востребованным

Очень малое количество ИТ начальников понимают необходимость структурного подхода к тестированию.
А внедрить такую систему снизу мало реально

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

Ведь мы пишем тесты, чтобы ПОТОМ наши доработки не сломались, а это потом обычно и остается на потом

(173) Олега сложно не узнать. Написал бы лучше, что это вообще за фото)

(174) ну и я о том же - от проблемы надо исходить.

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

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

ПриходнаяНакладная.НажатьМоюРазработаннуюКнопкуКотораяДелаетСкидку();
ОтчетСНовойСкидкой.Показать();

Еще это называется ДемонстрацияЧерезТестирование ;-) - так пробудет Ваня Берездецкий и команда где он работает (хотя по моему они периодически забивают и на это).

То есть тестирование - фактически "Кнопка нажималка" перед демонстрацией заказчику и во время деонстрации.
После этого акт выполненных работ и деньги на бочку ;-)

P.S. Артур сейчас будет ругаться - фактически здесь тестовый код пишется после самой разработки: но зато он хотя бы пишется и пользователи не тестируют руками.

(178) фото это с тренингов Асхата Уразбаева и ScrumTrek по внедрению инженерных практик при разработке, тот самый "соседний" мир "кошерных" платформ. Как говорит EvilBeaver - может поэтому БухгалтерияПредприятия сейчас с каждым днем выглядит всё привлекательней и привлекательней.

(173)
- Дамы, а давайте играть в карты на раздевание
- Поручик, вы посмотреть хотите или похвастаться?

Ну Фогель, ну без бороды. К Моничеву вас не подпустили, я так понимаю? И правильно сделали.

В общем, в подкорку четко вбито: ТДД -> внедренцы xUnitFor1C -> Лустин нагло сказал что нам это не надо, и вообще вы превращаетесь в дубов.
Спасибо большое за ценный совет и разработанный продукт.

(180) Я уважаемый, Вам лично, ничего нагло НЕ говорил.

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

С xUnitFor1C придется думать и кодировать по другому, поэтому я посоветовал начинать с простого "ночного" синтаксического контроля. Затем первый дымовой тест на открытие всех форм. Потом уже что-то серьезное.

То есть я советую не разрабатывать через тестирование сразу обычным 1С разработчикам, а начать с простой автоматизации собственной деятельности - например получение актуальной версии их хранилища https://github.com/xDrivenDevelopment/AutoAdmin1C/blob/develop/Scripts/retrieve_storage.os чтобы сделать каталог версий CF файлов

Отсылка к дубовому форума - была не персонально к участникам дискуссии, а к ее формату в стиле http://vapaus.ru/

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

Эээ
Просветите незнающего
Я так понял есть два конкурирующих подхода
Или что?

(179) А можем быть она выглядит привлекательней и привлекательней благодаря стараниям ее разработчиков?

Не умаляя тренингов Асхата Уразбаева (вообще о них ничего не знаю) - но так говорить нельзя. Иначе поставщик туалетной бумаги на селезневку сможет заявлять, что благодаря его туалетной бумаге БП становится все лучше)

Имхо, все просто - запуск и обслуживание бензопилы очень отличается от запуска и обслуживания самолетного двигателя. Было бы глупо на бензопилу заводить формуляр двигателя, записывать все запуски, времена работы, вести подробный учет каждой детали. И таки да, бензопила заводится гораздо быстрее и дешевле, чем самолетный двигатель.
Поэтому, имхо, если человек не видит выгод автотестирования, скорее всего, его продукт еще не дошел до масштаба/необходимости их применения. С другой стороны, если человек начинает задумываться о таких вещах, скорее всего продукт уже вырастает из коротких штанишек. Разработчик чувствует, что что-то уже не так, но что именно, и куда дальше тыкаться - еще не понимает.

(182) да именно - 2 подхода.

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

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

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

(183) Асхат, а точнее 3 команды ScrumTrek, SystemAproach и UnusalConcept занимаются повышением уровня качества команд разработки в сотфтверных компаниях

http://scrumtrek.ru/ - для разработчиков
http://www.system-approach.ru/ - для менеджеров продуктов и системных архитекторов
http://www.unusual-concepts.ru/ - для владельцев ИТ бизнеса

в НЕ 1С мире очень известные товарищи - выходцы из кузницы LuxSoft по-моему.

(0) Кстати - в НЕ 1С мире тоже идет большая война: как тестировать и сертифицировать. Причем процесс сертификации описан в том же ГОСТ, но простого способа "прогнать поведение системы" под конкретной версией Windows и MSSQL пока не существует. В итоге многие C#, Java, ruby и python программисты вполне себе осознанно забивают на всякие эти ваши методики.

(185) А есть подробное описание "для чайников" с чего начинать 2 подход, какой и как использовать софт и т.д?

Кто-то тут писал, что я пришел и начал двигать наш продукт по тестированию. ИМХО ЗаписьДампа писал.
Это неверно, т.к. в этой теме народ еще в декабре писал о нашем продукте xUnitFor1C.
Как Алексей написал, есть разные подходы по разработке и тестированию.
Есть ТДД - разработка через тестирование.
Есть другой подход (185) - сначала идет автоматизация на сервере сборок, и постепенно добавляются разные тесты, в режиме ТДД или без него.

Главное - автоматизируйте свою работу и не замыкайтесь только на 1С. Используйте чужие полезные практики.

Все равно в обоих случаях используется наш продукт xUnitFor1C для различных видов тестирования. Даже сценарные тесты 8.3 поддерживаются :)

ИМХО аналогов в мире 1С для него нет и вряд ли вырастет без участия компании 1С.

(174) Среди 1Сников, как и везде, работает правило "80-20".

(185) Подробное мы попробовали в виде блого-записи http://www.silverbulleters.org/obyichnyiy-start-rabotyi-obyichnogo-programmista-1s/

Потребуется:

шаг "первый":
1. TeamCity
2. SourceTree + MsGit
3. Gmail акаунт
4. Bitbucket акаунт

шаг второй:
1. 1Script - https://bitbucket.org/EvilBeaver/1script/wiki/Home - качать лучше последнюю версию инсталятора http://ci.silverbulleters.org/job/1Script-Develop-Build/lastSuccessfulBuild/artifact/dist/
3. команда Create build plan
4. команда Create build step
5. Получить последнюю версию из хранилища - https://github.com/xDrivenDevelopment/AutoAdmin1C/blob/develop/Scripts/retrieve_storage.os - получаем CF
5. один скрипт написать самим - полученный CF файл проверить синтаксически ;-)

По памяти всё - по моему это даже домашнее задание на одном из курсов

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

(191) если у вас проблемы с тормозами файловой бухгалтерии - это другой курс-практикум ;-)

Хотя 1С тестирует на пользователях :)

(175) (176) (177)
Есть такое. Начальнику тоже надо дозреть.

Большие конторы быстрее приходят к пониманию, что что-то надо менять.

Лучше начинать с малого. И дело пойдёт.

(192) там (см. Какие вести с партнёрского семинара? БП 2.0 закрывают? 8.3.6.x выпускают? ) авторам душевных криков аналогично еще не ответили ?)

Заказали у бита сделать правила обмена между ут 11.1 и бух 2.0.
На самом деле складывается ощущение что они свои правила никогда не тестят. Написание правил по выгрузке 3х документов длится уже месяца полтора, но по правде сказать хотелок у бухов тоже дофига, но тоже проверять их наработки запарился уже. Хотя в этом есть очевидный плюс, теперь я хоть немного стал разбираться в конвертации.

Что ты хочешь от расставлятелей галочек
Какой квалификации?
Нет у них понимания поэтому и идет так все долго

(197) Может это поможет http://infostart.ru/public/328695/

Все никак не доберусь - собираюсь написать пару приемочных тестов с использованием RSpec, Capybara и Poltergeist. Суть в том, что Poltergeist откроет веб клиент 1С, Capybara пощелкает кнопки и сообщит что и как.

В приложении на Ruby on Rails уже около 100 тестов, а покрыто только процентов 20% функционала.

(198) посмотрим

Желающие могут посмотреть мою статью на Инфостарте http://infostart.ru/public/326820/
"Механизмы тестирования в 1С. Использование методики TDD (разработка через тестирование) в 1С"

Данная статья написана по материалам доклада, прочитанного автором на первой конференции инфостарта 2012 года. Она опубликована в журнале Инфостарта №1.

(202) в статье, новый метод 4 изобрел "парное программирование или обзоры кода"

это так то не "один пишет – один контролирует", а "один пишет|кодирует - один командует|управляет|говорит что писать"

т.е. это похоже на прораба и работника

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

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

ЗЗЫ метод правильно называется "программирование на коленях"

(203) Весь смысл именно в паре, а не в командовании :(
прочитай внимательно еще раз этот абзац из статьи.
один пишет, другой рядом контролирует, задает вопросы, уточняет и т.п.
в этом максимальная польза.
И это давно известный принцип экстремального программирования.

угу.. видно, что типовые явно в некоторых местах писали экстремалы ;-)

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

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

проверено на себе и других подопытных :)

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

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

(204) согласен что 2-й который пишмашинка может вставлять свои 5 коп.


но он не главный, т.е. последнее слово не за ним!

там дальше есть такое правило )) если он считает что надо не так...то работающий головой без вопросов садится за клаву и говорит "ну давай говори как надо сделать - командуй дальше"

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

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

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

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

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

.

У как говорят у нас горнолыжников-программистов:
- В экстремальном программировании главное - вовремя понять где кончается экстрим и начинается pizdec

(211) юлин. где я этот "готовый ответ для тестовых данных возьмму"..?

(213) от заказчика?

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

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

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

Блина
Есть желание гдето чтото улучшить
Но как
Пока непонятно

вот блин типовые конфиги мамы
Они вообще както тестируются
Какова внутренняя кухня
Кто в курсе?

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

(0) > как определить минимальный набор тестов, покрывающих нужный функционал..?

Зависит от простоты алгоритма. Если алгоритм прост, то тестирование нужно шапочное, однако, если алгоритм сложен, то его надо покрыть тестами.

Пример сложного алгоритма: реализация односвязного списка на с++ и т.п.

(99) 1. легко. и могут быть более затратными в человекочасах.

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

(219) >Кто в курсе?

не знаю как в типовых, а у нас тесты делятся на три типа:
1) человекотесты - ищут «непредсказуемые» глюки
2) автотесты - проверяют результаты экспортных процедур/функций и функциональность создания объектов
3) пользователи - ну тут как у всех.

(219) Хреново они тестируются. Регрессионного тестирования нет. Есть следы автоматизированного тестирования с различными типами клиентов и только. В прошлом году 2 раза регистрировал ошибки, возникшие из-за некачественного тестирования БП перед релизом. Просто функционал не запускали после сборки релиза ни разу.

(218) Любое улучшение нужно начинать с поиска проблемы/ограничения...

Все проблемы там где не автоматизировано -в неспособности выполнять и согласовывать простейшие действия между двумя сущностями-людьми

Злой я шо капец

(226) нее, проблема в коммуникациях...

т.е. как заказчик может объяснить что он хочет, если он сам не знает что ему надо?

и наоборот как исполнитель может делать софт для заказчиков, не разбираясь, не поработав как они?

вот недавний яркий пример это УТ11, вот почему они почти допиленную УТ10.3 просто не переписали на УФ?

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

причем писали явно полные 7-ники ))

(227)+ причем походу ЗиК-цы ))

(227)  то что проблема в коммуникациях это однозначно

(227)  тв это... На семерочников то не гони...

Ну както двигаться вперед надо
Вот и переписывают по сто раз одно и то же

(230) дык как на знатоков 7.7 и не думал

но вот такими же методами, причем копи-паст из конф 7.7 это что?

(231) движение ради движения? это какой то m$ и abode выходит

(233) в результате выигрывает не то кто новое-лучшее придумывают, а те кто "лучше двигаются" т.е. новые версии г* выпускают

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

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

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

(226) Аналогично, коллега. Может тебе пора уже soft skills осваивать? В hard skills у тебя и так компетенция заоблачная для текущей деятельности-то...

(235) тогда каким образом это метод программирования? каким образом и чем он отличается от обычной совместной разработки группой из 2-х и более человек? причем даже тимлида нету ))

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

система мастер-подмастерье работает, система 2 мастера без разделения задач или без старшего мастера сверху нет

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

(239) Да их толковый менеджер за неделю научит правильно работать. Особенно если техническими навыками не обладает. После 5-10 сеансов реализации каждого из мнений с разбором плюсов и минусов полученных результатов code monkey сами научатся в спорных случаях делать оба варианта и проводить ретроспективу.

(240) т.е. надо найти 2-х скиллнутых прогов на 1 задачу? а смысл?

если 1-го то найти проблема не говоря уже о том что 2-е одну задачу в 2 раза быстрее не сделают ))
но могут сделать в примерно 1,5 раза лучше

(241) Один скилловый прог:
Сомневается в каждом своем решении. Пока сомневается - раздумывает и не кодит.
Имеет запущенный мессенджер
Имеет запущенный почтовый клиент
Вспоминает, что еще не читал хабр

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

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

(242) не видел )) без надсмотрщика сзади за спиной с табелем. чтобы такое работало...

скорее они будут в хероев причем онлайн играть двоем ))

(232)  вопрос к тем кто подбирал команду для написания конфиг

(236)  у меня нет никаких сомнений в необходимости тестов и втотестов при командной разработке
Хотя бы потому чио мой опыт меня учит что большинство проблем именно на стыках
А при командной разработке я думаю этих стыков пруд пруди
Где поймают там и пруд

(237)  елы палы дай хоть ссылку почитать про софтскилл и хардскилл

(242)  в результате код такой что смотреть противно
Ибо ни томуни другому не хватило времени хабр почитать по теме кодируемого
Ибо пишут код блеать с дикой скоростью

Забыл поставить мегасмайл

(248) такой ?

????????????????????????
????????????????????????
????????????????????????
????????????????????????
????????????????????????
????????????????????????
????????????????????????
????????????????????????
????????????????????????
????????????????????????

(249) (( блин в кодовой таблице нету этих ASCII символов

(250)+ http://text-image.ru/news/dobryj_smajlik/2014-03-18-5314

(243)  не ну почему
Я видел и сам участвовал
И перло нас в паре с челом с которым мы работали нереально
Просто потому что мы иогда были молодые
По 20 лет
Хренячили с дикой производительностью на ассемблере так что только перья летели
Разрабатываемая прога тестировала сама себя -новый пишущийся функционал
Как снежный ком наращивалась

За пять дней с нуля освоить ассемблер узкоспециализированного аычислителя
На кроссассемблере запрограммить незеровую программу
Отладить это все прогнать и сдать в эксплуатацию
Это да
Это было
И не надо было нахрен никаких тдд эджайлов и прочего
Просто потому что перлонереально
И главное потому что жто было комуто реально нужно

А сэтой одноэсиной такое впечатление что постоянно в куче дерьма копаешься
Это как сервячок сынок говорит папечервячку
Папа вот пчелки цветочки
Вот бабочки цветочки
Почему мы то в говне?
Потому что сыное - Родина!

(246) Ну вот вроде статья неплохая: http://futurecenter.in.ua/pratsevlashtuvannya/korysni-porady/hard-yly-soft-skills-chto-vazhnee-dlya-menedzhera/ (252) Вот так оно и началось. Посмотрели умные люди на 20 летних пацанов, которые жгут, и подумали: "А мы чем хуже?"

(253) эээ? типа греки/римляне мочили за счет софтскиллс всех варваров с хорошими хардскиллс ?

индивидуально любой варвар уделывал 2-3 греков/легионеров

но вот фаланга/легион уделывал любую толпу варваров на раз ))

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

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

и будет конкретный такой хардскиллс с этого момента

(253)  фраза а чем мы хуже чем то мне напоминает филььм тупой и еще тупее часть два
;-)

(253)  спасибо
Отправил ссылочку своим руководителям

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

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

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

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

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

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

Сам недавно приобщился к хЮнит и уже пару раз он мне помог

Единственное что в для хЮнита ОЧЕНЬ мало документации, примеров, бест практис

В первую очередь по-любому smoke test. А дальше зависит от заказчика задачи. Если внешний - то 1ый пункт, если внутренний - то 2ой.

https://ru.wikipedia.org/wiki/Smoke_test

(261)  хотелось бы поподробнее
Что сподвигло
На чем проверял
Какие результаты ощущения

(260) Да, сложный этап "создание тестовых данных" всегда сильно осложняет создание тестов.
Вот для этого я в xUnitFor1C и добавил генератор макетов данных на основании реальных данных.
В итоге создание данных очень сильно упростилось, и сейчас на это тратится мало времени, основное время уходит на код самого теста и его проверку.

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

(262) Работаю над этим.
Скоро выпущу статью с реальными примерами использования xUnit

(267) Скоро это когда, примерно хотя бы. И где ловить анонс новости?

(268) Инфой о новых релизах xUnitFor1C обычно я делюсь в Гугл+.
Статью выложу на одном или нескольких ресурсах (http://www.silverbulleters.org, Инфостарт, Habrahabr)

(259) Если ведешь разработку своей конфигурации и если есть ресурсы - то да, надо пробовать. А при обычной работе 1С-ников - вряд ли.

(260) Так автоматическое создание контрольного примера то тоже надо настроить, то есть придумать пример, указать какие объекты надо создать и как они должны быть заполнены. Это ведь еще больше времени, чем просто его вбить. Как правило вбил его в базу один раз и потом его гоняешь. Если надо - уточняешь.

(271) Ты в любом случае это делаешь когда первый раз разрабатываешь.
Или ты вслепую пишешь код без данных?

(271) смотри (265) и http://goo.gl/Sn9eYO

(272) В любом случае

(273) Если вкратце, это что-то переброски объектов между базами?

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


Процедура тестСоздатьКолонку() Экспорт
    ТЗ = ТЗ();
    Сам().ПроверитьРавенство(ТЗ.НоваяКолонка("К1"), 1);
    Сам().ПроверитьРавенство(ТЗ.НоваяКолонка("К2"), 2);
КонецПроцедуры

Процедура тестСоздатьКолонку_Ошибка() Экспорт
    ТЗ = ТЗ();

    Сам().ПроверитьРавенство(ТЗ.НоваяКолонка("К1"), 1);
    Сам().ПроверитьРавенство(ТЗ.НоваяКолонка("К2"), 2);

    Сам().ПроверитьИсключение(Сам(), "НовКол", Сз(ТЗ, "К1"));
    Сам().ПроверитьИсключение(Сам(), "НовКол", ПолучитьПустоеЗначение());
КонецПроцедуры

Процедура тестСортировкаПоУбыванию() Экспорт
    Сам = Сам();
    ТЗ = Выборка_ЗаполнитьТЗ();
    ТЗ.Сортировать("-к1");

    Сам.ПроверитьРавенство(ТЗ.ВыбратьСтроки(), 1);

    Сам.ПроверитьРавенство(ТЗ.ПолучитьСтроку(), 1);
    Сам.ПроверитьРавенство(ТЗ.к1, 15);
    Сам.ПроверитьРавенство(ТЗ.НомерСтроки, 2);

    Сам.ПроверитьРавенство(ТЗ.ПолучитьСтроку(), 1);
    Сам.ПроверитьРавенство(ТЗ.к1, 10);
    Сам.ПроверитьРавенство(ТЗ.НомерСтроки, 4);

    Сам.ПроверитьРавенство(ТЗ.ПолучитьСтроку(), 1);
    Сам.ПроверитьРавенство(ТЗ.к1, 5);
    Сам.ПроверитьРавенство(ТЗ.к2, 1);
    Сам.ПроверитьРавенство(ТЗ.НомерСтроки, 1);

    Сам.ПроверитьРавенство(ТЗ.ПолучитьСтроку(), 1);
    Сам.ПроверитьРавенство(ТЗ.к1, 5);
    Сам.ПроверитьРавенство(ТЗ.к2, 2);
    Сам.ПроверитьРавенство(ТЗ.НомерСтроки, 3);

    Сам.ПроверитьРавенство(ТЗ.ПолучитьСтроку(), 1);
    Сам.ПроверитьРавенство(ТЗ.к1, 1);
    Сам.ПроверитьРавенство(ТЗ.НомерСтроки, 5);

    Сам.ПроверитьРавенство(ТЗ.ПолучитьСтроку(), 0);
КонецПроцедуры

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

(272) В целом, да, но "Переброска объектов между базами" совсем уж кратко :)
ИМХО простой, быстрый, удобный интерфейс создания тестовых данных именно для разработчика.

У нас народ даже начал этот механизм начал юзать для создания новых данных при обновлении ИБ :)

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

Когда-то и тестов для 1С++ было 10 :)
а для xUnitFor1C 1 :)

а сейчас у 1С++ за 1000 тестов (правда, с 2006 года их количество почти не менялось)

а у xUnitFor1C 300 тестов. Правда, выполняются они в разных платформах (5 - 8.2.13, 8.2.17, 8.2.19, 8.3.4, 8.3.5) и режимах (3 - обычное приложение, тонкий и толстый клиент управляемого приложения.
так что можно смело умножать на 5*3
и итоговое число тестов 300 * 15 = 1500 тестов :)

(279) Упс, с арифметикой всегда было плохо, а с математикой хорошо :)
всего 4500 прогоняемых тестов :)

(276) как понять, какой тест является обязательный, а какой - избыточным (лишним), то есть входит в подмножество другого теста?
.
вот, например, Даты в таблице значений
пробовал.. тупо не задумываяфсь накидал алгоритм реализующий задачу и начал подсовывать тесты (там же, топик 11). Полезли ошибки, начал модифицировать алгоритм, чтобы исключить ошибку, ну и крутил так пока приходилы мысли КАКОЙ ТЕСТ ЕЩЕ БЫ ПОДСУНУТЬ. Когда мысли насчет какой тест подсунуть иссякли, все тесты выдавали результат правильный - на этом остановился).

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

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

(277) в (276) нихрена не понял...

(281) Без обид, но это эпичный мем :)
"пришлось бы для каждого написанного теста решать задачу вычисления правильного результата -а это дольше чем просто увидеть что результат неправильный)." :)
т.е. ты знаешь, какой результат правильный, но не можешь это сформулировать :)
На самом деле, это типовая проблема!
пока мы не сможем сформулировать критерии приемки, завершения работы, сложно передать работу другому человеку (заказчику, тестеру, соседу-разработчику), так и автоматизировать тестирование.
Нужно в первую очередь как раз получать критерии приемки/завершения с некоей формализацией.

А я сохраняю традицию фирмы 1С...

(283) без обид... но тогда будет сплошной индусский код

т.е. наваяли...оно тесты не проходит...нафига переписывать когда можно под прохождение тестов патчу сделать заодно и больше заплатят т.к. кода будет БОЛЬШЕ!

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

Как правильно реализовывать цепочки тестов.
Пример:
Вводим пту > вводим доп расходы > вводим РТУ - прверяем партии.

Каждый тест должне проверить интерактивную работу документа + сравнить движения

Что лучше
1 вариант: каждый тест создает свой документ. все тесты запускаются строго полсдовательно. + удаление данных. либо перед тетами либо после
2 вариант: каждый тест загружает все необходимые данные и тестирует себя. последовательность не важна. удалять данные можно сразу полсе выполнения теста

(287) Это вопрос или ответ?

(285) Не совсем понял.
Какую патчу?
что-то я не замечал индусского кода у тех, кто тесты пишет :(

(283) блин, ну так это и есть основной вопрос во что упирается написание тестов - то есть по сути это формализация приемки задания. А если эту формализацию заказчик сам сформулировать может только очень округло - то все это тестирование (то есть приемку работы) - провожу я вместо заказчика. а мну-то за эту работу никто не платит... ;-)
.
как раз пару раз при попытках разместить на фрилансах мелкие задания которые влом самому делать было так ипроисходило - прог: А вот готово! а я ему: идите нафиг, ибо вот так получается криво! и по новому кругу - меньше 5-6 итераций не получалось. дальше я уже уставал... и расходились с той или иной степенью удовлетворенности друг другом.

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

(289) а нафига в (276) процедура тестСоздатьКолонку() - которая нигде не вызывается?

(289) Это и есть тестовый метод, который вызывается извне фреймворком тестирования.
для тестов 1С++ было важно, чтобы имя теста начиналось на тест, метод был экспортным и без параметров.

(290) Вот именно, если бы ты ему дал более точные критерии, было бы меньше итераций :(
но помимо тестирования лучше еще и ревью кода делать, и кросс-тестирование и т.п.
(291) любое занятие можно превратить в искусство.
Минус любого тестирования - тестирование никогда не найдет все 100% ошибок.
На самом деле все просто, но ошибки можно и пропустить по разным причинам.

(289) эээ? когда это тесты писали те кто пишет код? они пишут процедуры/точки входа для запуска тестов в своем коде

а вот кто пишет тесты (тестовые данные) и запускает их согласен не индусы

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

(294) стоимость такого "программиста 1С" по моему мнению стремится к очень низкой величине, в противовес ожиданиям этого самого "программиста 1С"
.
повбывав бы..
.
(ну и меня наверное тоже повбывали бы)

(295) это запросто ;-)
еще когда служил, колбасится у нас народ, сдает/готовит курсовую (по второму образованию, что-то там на фиников/итп). Приходят, Сергей, глянь, ты ж 1Сник, что-то у нас все правильно, но при этом "не сходится..."... ну я значит с высоты так грю с протяжной ленцой поиивая виски и покуривая сигару ;-) - давайте, мол, глянем вас болезных... ;-) минут 5 заняло.. там они эти курсовые клонируют друг у друга, склонировали у какой-то девки, все в экселе куча таблиц листов, в итоге в столбике одном итог ну никак не совпадает с суммой по столбику... а фигли - стоит ручками в ИТОГЕ нужная цифирь и все... ;-) Отдал... Поиздевался конечно малость - как без этого ;-)

(295) >>когда это тесты писали те кто пишет код?
Очень и очень часто.
когда нет тестеров, когда работают через ТДД, когда работают в хороших командах, когда являются хорошими разработчиками :) и т.п.
А тестеры бывают очень редко.
А после кризиса будет еще меньше.

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

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

еще тесты практически бесполезны для гуи, а >50% на 1С это интерфейс для пользователей

(300) уровень продвинутости - неважен.
У меня в команде 5 разработчиков.
Не реально держать в голове все контексты, все ньюансы кто/что делал. Договариваться приходится постоянно.

>"еще тесты практически бесполезны для гуи"
пиши UI тесты, если UI на проекте очень важен.
Для этого могут понадобиться специфичные инструменты, типа Sikuli IDE. Но ничего нерешаемого тут нет.

(300) Тесты ГУИ писать лучше пореже, слишком это неблагодарное и сложное дело.
Лучше всю бизнес-логику выносить из ГУИ, чтобы слой бизнес-логики был изолирован от формы.
и тестами покрывать именно бизнес-логику, а не код формы или еще ГУИ.

(301) ух ты! а вкратце - какова идеология-подходы по тестирования гуи?

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

(304) вот и выдели бизнес-метод "Жмак на сканере ТСД" с набором параметров.
Твой Гуй вызывает только этот метод с передачей параметров. в Гуе минимальная логика, вся логика в бизнес-методе.
И тесты нужно делать именно на бизнес-метод.
Еще такая схема называется как доменная модель :)

(303) идеологий много, но лучшая - это не тестить Гуй :)
Тестирование ГУИ относят к верхнему уровню (Икроу :) по пирамиде Маслоу), как и приемочные.
Но часто путают приемочные и Гуи-тесты
Можно получить пользу от этих тестов, но очень сложно найти бывает найти ошибку, если эти тесты падают, т.к. причин ошибки может быть масса.
ГУИ-тесты очень медленные (тот же Селениум), поэтому они запускаются довольно редко.
И пользы разработчику приносят мало.
Т.к. по упавшему тесту часто приходится долго разбираться, где же ошибка :(

(305)  такая модель построения будет содержать состоять из дофигища связей гуя с кучей кусочных бизнеспроцессов
Меой мелкий опыт говорит что большинство проблем возникает на стыках
Здесь же таких стыков на уровне интерфейс-кусочек бизнеслогики просто офигеть
Както так я себе представляю
Давайте посмотрим на тонкого клиента
Это приерно оно и есть
Получили чтото от гуевогофейса и переправили на серверв бизнеслогику
Все это ворочается не сильно быстро
Както так

(307) Так это и есть нормальный путь - выделяем куски от бизнес-процесса (классы, модули, объекты, сущности) и их автоматизируем.
А ты хочешь все в одной БА-А-АЛЬШОЙ процедуре с именем "Бог" держать :) ?

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

(309) Может быть, уйду, а может быть, и нет.
Все зависит от задачи, от опыта, от проектирования и т.п.

(310)
То есть,нужно еще на этапе проектирования закладывать оптимальную для автоматизированного тестирования архитектуру?

Благое устремление, но как быть с текущей реальностью?

(308)
Много разных слов.
Очень интересно, тема действительно крайне актуальная, но никакой конкретики.

Можешь на простом примере в любой типовой "на пальцах" объяснить как работает технология.

(303) Возьмём крайний случай.
Представь, что пишешь какой-нить Angry Birds.
И тебе важно, что именно вот в этот момент игры на экране появилась именно эта надпись.
Или наоборот. На экране появилась реклама, но она не должна была заслонить основные элементы управления.

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

Чтобы искать что-то на экране, используют специфичные инструменты. Мне нравиться Sikuli IDE, это по сути скриптовый движок, язык - питон. Есть и другие движки.

Что же касается 1С - то это чаще всего нафиг не надо.
Заказчику важна бизнес логика, а не координаты кнопки на экране.

(312) непонятно, что именно нужно объяснить.
Жду уточнения.

(314)
Как технология работает на практике
Живой пример теста.
Желательно понятного всем присутствующим и не оторванным от жизни.

(315) это бесполезно. Я уже этих апологетов неоднократно спрашивал: как протестировать СКД? Ноль конкретики. А "дважды-два" тестировать бессмысленно.

И на вопрос "надо ли тестировать тесты?" я тоже не получил ответа

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

(316) что-то я твой вопрос по СКД не видел.
Уточни, что именно ты подразумеваешь под "как протестировать СКД" ?

(315) тут уже было много слов и бросаний в разные стороны.
Так что твой вопрос не очень понятен.
какую технологию тебе нужно пояснить?
ТДД или как вообще тестировать или как ГУИ отделить от бизнес-логики или еще что?

(319) Пока ты не ответил, попробую протелепатировать :)

Вот тебе готовый тест проверки отчета на СКД.
В тесте сначала создаются тестовые данные в базе, затем выполняется отчет на СКД, получается сводная таблица.
Эта таблица сверяется с эталоном.

http://goo.gl/hMiHHB - можешь скачать сам файл теста (это обработка
http://goo.gl/6z4H6A - текст самого теста (этой обработки)
http://goo.gl/jGOFI7 - скриншот эталонного результата работы СКД

Что скажешь? помогло?

+(321) В Вики xUnitFor1C http://goo.gl/Hhdh4T я документировал этот же пример.
Там изучать поудобнее :)

(322)  все равно не понимаю
Таблица отчета на скд сверяется с эталоном
Откуда берется/взять эталон?

(321) вот с момента "сначала создаются тестовые данные в базе" можно подробнее.

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

(316)
"Я уже этих апологетов неоднократно спрашивал: как протестировать СКД"

А ты знаешь толк в извращениях).

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

(326) а зачем мне тестировать 2+2?
Пусть научат добрые люди, как в рамках проповедуемой ими TDD нарисовать простенький отчет на СКД.

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

(323) Эталон - это результат работы твоего функционала на определенных входных данных.
Например, для функционала "Сложить 2 и 2" эталоном будет 4.
А результат берется из описания работы твоего функционала и понимания критериев завершения.

(329) Функционал — это отображение некоторого множества в число. Я не понимаю, о чем ты говоришь.

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

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

(330) Вот теперь я тебя перестал понимать :(
какое множество?
у тебя есть функционал, который умеет складывать 2 числа.
Исходные данные: Значение1=2 и Значение2=2
Функционал: Рез = Сложить(Значение1, Значение2)
Результат: в переменной Рез.
Эталоном для Значение1=2 и Значение2=2 служит число 4.
вот тебе и тест, и эталон.

(328) В целом про заглушки/моки ты прав, но причем здесь 1С и СКД ?

(333)
Вероятно "заглушки" это и есть тестовые данные.

(331) Вот например имеем отчет на СКД, в нем используется 20 временных таблиц. Т.е. я должен создать эталонные данные на все 20 таблиц, и тестировать "снизу вверх", постепенно заменяя эталонные ВТ выборками из БД?

(332) Функционал — это математический термин. Когда речь идет о реализации некоторого набора операций в программе, принято говорить "функциональность".

(335) Именно. Точнее, ты должен создать N наборов контрольных данных, где N — количество тестовых случаев.

(337)+ причем, согласно TDD, ты должен их создать __до того__, как напишешь сам отчет.

(332) такие примеры слишком оторваны от жизни

(339) А процедуры вообще так просто не протестируешь

(338) Ага, и при каждом уточнении ТЗ пересоздавать их заново...

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

(341) Если изменение тз влияет на 20 случаев - то нужно пересоздавать все 20 тестов.
Ведь при разработкетоже придется прогонять все 20 тестов заново

(342) как раз на таких пример не видно ничего. Поэтому и идет непонимание. "Зачем проверять 2+2?"

(335) >>СКД и 20 временных таблиц.
Таблицы созданы по данными ИБ или подставляются откуда-то извне?
ИМХО неважно, сколько таблиц юзается. важно, какие данные юзаются.
Вот в тесте желательно эти данные и создать.
Есть жесткая методика/требование - работать в чистой базе, и все данные создавать с нуля. Это довольно сложно, но максимально эффективно.
xUnitFor1C сильно помогает решить эту задачу.
Есть методика не столько жесткая - работаем в какой-то заполненной базе. данные создаем редко, и тесты прогоняем на этой базе.
Здесь низкий порог входа. Я сам им периодически пользуюсь.
Но при использовании разными разработчикам возникают проблемы - тесты могут тупо не работать у соседа, т.к. у него своя ИБ и данные различаются.
И начинаются проблемы :(

(341) (343) Если исходные требования меняются, то тесты также, возможно, придется менять. Но наверняка, не все 100% тестов, а только часть.
И это нормально.
Как раз тесты и помогают быстро переключаться на новые требования.

(337) Не понимая в вопросе, о котором споришь, решил блеснуть собственными знаниями? Так ты бы сразу ветку в бан с формулировкой "Ничего не понимаю, значит этого не существует".

(347) ты хочешь в бан? это легко устроить

+347 ошибся постом, к (336) обращено.

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

(350)
Тем не менее практическая польза все таки есть.

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

Особенно помогает при доработке прав и ролей.
Не все естественно - но хоть как то страхует от "тупых" ошибок.

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

(351) Да я против что ли?
Но есть нюанс©
Вот статья уважаемого artbear на ИС, в которой поётся всё та же мантра "TDD — это благо, с TDD нам всем будет хорошо".
Начинаешь продираться, искать смысл — ноль конкретики.

Пока получается, что TDD — это Trash Driven Development©
(применительно к 1С)

(354) Ну это слишком радикально. Просто данная технология имеет предельно узкую нишу применения при разработке в (на) 1С. И декларирование ее "серебряной пулей" несколько самонадеянно...

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

BDD — Bullshit Driven Development©

(353) Грубо для себя я понимаю так:

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

1 Без тестов
написал прототип - час
потестировал - час
порефакторил - час
потестировал - час
пооптимизировал - час
потестировал - час

Итого 6 часов

Вроде как есть рутинная операция тестирование, которая в данном случае не меняется. Более того, даже при добавлении функционала как правило старые тесты тоже должны отрабатывать.

Поэтому вроде как получается экономия:
написал тест - час
написал прототип - час
поправил тест - час
порефакторил - час
пооптимизировал - час

Итого 4 часа

Я правильно понял смысл тестирования?

Ой, обсчитался - 5 часов. Но чем больше циклов модификации, тем больше выигрыш.

(358) Нет, в TDD ты сначала пишешь тест. Потом добиваешься, чтобы он проходил хоть как-нибудь. Потом пишешь еще один тест, добиваешься, чтобы проходило два теста. И т.п. Потом рефакторишь, попутно смотришь, чтобы тесты не сломались.
Потом приходит изменение требований. Ты изменяешь тесты в соответствии с ним. А потом добиваешься, чтобы тесты не ломались.

(358)
Неверно
Тест тоже нужно менять после рефакторинга.

(360)+ при этом не забывая, что тестировать надо не только успехи, но и фейлы.

Про тестирование СКД.  А в чём собственно проблема?

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

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

(362) Для первого шага достаточно только успехи тестировать

(363)
)

(360) 1. главное, помнить, что догмы это плохо.
поэтому не всегда можно/нужно работать в режиме ТДД.
Хотя ТДД очень удобно, позитивно и повышает надежность и т.п. :)
2. Цитата: "приходит изменение требований".
Как правило, когда тестов много, изменение требований не слишком влияет на тесты.

(353) Цитата "Начинаешь продираться, искать смысл — ноль конкретики."
я тебе уже много конкретики дал.
по СКД ты мне так и не ответил.

(367) Так я свои претензии к вашему подходу тестирования СКД уже высказал неоднократно, и коллегам это очевидно.

пусть будут придирки, а не претензии

Мутотень какаято
Пока что делаем так
Пишем код
Пишем тщательно сразу используя навыки как умеем

Потом тестируем
Как минимум на граничных значениях и всяких аналогичных нежданчиках типа пустых значений несоответствие типов и прочее
Сидим смотрим в код и пытаемся выродить тесты которые поломают систему

Както так я обычно действую
Ну и зачастую большинство не тестирую или тестирую очень слабо
Сложные вещи тестируются в эксплуатации
Да бывают крупные бяки изза этого

Но никто же не дает бпбла на наем тестировщика и прочее нужное
Потому что зачастую к ит отношение такое

давайте отойдем от СКД и рассмотрим более простую задачу. Элементарную, я бы сказал.

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

тестирование интеграций с другими системами - это отдельная песня

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

(370) для "нежданчиков типа пустых значений" заведите вот такое:

Функция _Поумолчанию(НужноеЗначение, ДругоеЗначение) Экспорт
   Возврат ?(ЗначениеЗаполнено(НужноеЗначение),НужноеЗначение,ДругоеЗначение);
КонецФункции

(371) например


Функция тестСервисДоступен()
    Возврат МодульСервис.Доступен();
КонецФункции

Функция тестМЖ()
    Если НЕ МодульСервис.Доступен() Тогда
        Ошибка = "сервис недоступен";
        Возврат Ложь;
    КонецЕсли;
    
    Возврат ПроверитьРавенство(МодульСервис.Запросить("Вася", "Галя"), "МЖ");
КонецФункции

Функция тестЖМ()
    Если НЕ МодульСервис.Доступен() Тогда
        Ошибка = "сервис недоступен";
        Возврат Ложь;
    КонецЕсли;
    
    Возврат ПроверитьРавенство(МодульСервис.Запросить("Дуня", "Ваня"), "ЖМ");
КонецФункции

Функция тестММ()
    Если НЕ МодульСервис.Доступен() Тогда
        Ошибка = "сервис недоступен";
        Возврат Ложь;
    КонецЕсли;
    
    Возврат ПроверитьРавенство(МодульСервис.Запросить("Петя", "Серёжа"), "Недопустимые параметры");
КонецФункции

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

Кстати, вариант ответа на случай "сервис недоступен" в коде предусмотрен, его тоже неплохо протестировать

(376) как это разным? для одних и тех же входных параметров сегодня одно, а завтра другое?

для теста нужны 2 вещи:
набор входных параметров - констант
набор выходных параметров - констант

(378)
так разным, как курсы валют например

Функция тестПолучитьКурс()
    Возврат ПроверитьРавенство(ЭтоЧисло(МодульСервис.Курс()), Истина);
КонецФункции

(370) отчего мутотень

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


ситуация для УПП в части партий, НДС или взаиморасчетов типовая

и тестом является контрольный пример длинной в сотню операций , перекрывающий весь функционал УС


в таком раскладе кроме тестирования нет иных приемов

(378) Это текущий курс с ММВБ. Он может меняться несколько раз в минуту

(382) А что в этом случае тестировать то надо?

(382) Если ответ сервиса идет с состоянием "2хх", а содержание преобразуется в целевые типы данных 1С корректно - считаем тест пройденным.

(371)  полный перебор входных параметров
включая несуществующие коды валют, ошибочные форматы даты, выборку за 3015 год, нарушение формата любого из параметров стэка

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

По тесту, связанному с сервисом.
Это интеграционный тест.
Такие тесты достаточно сложны.
Лучше делить тесты на 2 части:
1 - сам интеграционный тест, который напрямую юзает сервис.
2 - внутренние тесты, которые не юзают сам сервис, а юзают некие идеальные/эталонные данные, которые МОЖЕТ/ДОЛЖЕН предоставлять сервис. Здесь юзаются заглушки (моки/стабы)

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

внутренние тесты должны проходить всегда на 100%

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

(387)[внутренние тесты должны проходить всегда на 100%]
100% включает в себя ошибки округления ?

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

(389) это опять проблема выбора тест.сценариев.
если считаешь округление важным, пиши тесты на это или вручную тестируй
если нет, не пиши и не тестируй вручную :)

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

(390)
Стесняюсь спросить тогда Ваша какая профессия?

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

ну и вариация теста из (375), когда отсутствие сервиса не наша проблема:

Функция тестМЖ()
    Если НЕ МодульСервис.Доступен() Тогда
        ЛогТестов("сервис недоступен");
        Возврат Истина; //ошибка не наша, но информацию надо видеть
    КонецЕсли;
    
    Возврат ПроверитьРавенство(МодульСервис.Запросить("Вася", "Галя"), "МЖ");
КонецФункции

(391) не о том, вопрос о границах применимости прямого тестирования и о его вариативности, ибо у любого метода есть разумные пределы

(386) "..Нужно выбрать только важные/критичные и их проверять."
- ну и как их выбирать?

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

(397)
Так все таки - как протестировать отчет на СКД?
Учитывая тот факт что пользователь может создать 23,5 варианта отчета и установить отбор сортировку, условное оформление  и по любому полю и это все должно работать
с учетом особенностей интерпретатора СКД.

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

(398) создать 23,5 вариантов входных данных, и проверить результат для каждого.
Как иначе то?

(400)
и рекурсивно прогнать все возможные варианты отбора и условного оформления, для каждого опять таки создав вариант входных данных для контроля.

Итого если у нас 10 полей в каждом по 10 реквизитов
23,51010

2 350 наборов водных данных для простого отчета на СКД

Как то неэффективно

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

(401) 2350 тестов, даже если каждый тест в одну строчку - да многовато.
Тут врядли можно придумать какой-то универсальный механизм на все случаи жизни. Я обычно делаю тесты на всякие замысловатые случаи, которые не укладываются в банальную схему (у нас тут банальные схемы свои, не СКД, и вообще семёрка).

(403)
вот в этом и вопрос - чем проще среда разработки тем более применимо прямое тестирование.

(404) вот поэтому мне восьмёрка и не нравится, а особенно СКД.
Оне же про это не думали. Совсем.

(405)
Счеты проще всего тестировать)

(401) А что ты сейчас делаешь, без автотестирования?
как проверяешь эти тысячи вариантов?

(394) Леша, я говорил как раз, что интеграционные тесты могут быть сложными.
И их нужно упрощать/разделять ответственность разными способами
Например, делить на 2 части - с зависимостью от сервиса и без зависимости от сервиса.

+(407) Читай еще раз (386).

(407)
Я лично ничего давно уже не делаю.

В конфигураторе

(406) Счёты тестировать вообще не надо. Тестировать можно только методы работы с ними. Но это уже не программно :)

(408) Ну я понял, ты говорил, что тестов понадобится тупо больше. Это да.

(387) 1. Это не интеграционный тест. Сервис - это просто источник данных.
2. Ничего сложного в его тестировании нет, достаточно поднять локальный веб-сервер с набором статических страничек. Это на порядки проще, чем делать тестовые базы для СКД.

(413) 1. Почитай определение интеграционных тестов. Любой тест, в котором участвует больше одной компоненты, модуля, блока может считаться интеграционным.
А уж если сторонний сервис, тем более интеграция.
2. ну поднимешь ты веб-сервер и набор страничек. неплохое решение для интеграционного теста, фактически это мок.
а что должен возвращать сервер, знаешь?
если знаешь, эта информация и есть тестовые сценарии.
след.вопрос - этот веб-сервер будет доступен только на твоей машине? а если разработчиков несколько? а есть уверенность, что твой веб-сервер повторяет функционал настоящего сервиса?
вопросов по твоему веб-серверу очень много. Его нужно поддерживать, он должен быть доступен. Как ты его будешь при появлении новых тест.сценариев? и т.п. и т.д.
2.1 где ты увидел, что нужно делать "тестовые базы" под СКД? я лично писал, что данные нужно генерить, а не базы :)

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

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

(396) Злопчинский, насколько я вижу, у тебя проблема с генерацией тест.сценариев.
Это стандартная проблема у разработчиков, пользователей.
Почитай про тест-анализ.
Также очень полезно узнать про классы эквивалентности.
Например, видел в постах про СКД 2500 вариантов.
А если подумать, можно выделить одинаковые/эквивалентные группы/классы сценариев, граничных значений.
За счет выделение подобных групп можно сильно уменьшить количество тест.сценариев.

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

Главное, не забывать выделять важные/критичные сценарии.
Например, мы знаем, что материалы мы не продаем, поэтому проведение РН с материалами можно не тестить.

(416)
"поэтому проведение РН с материалами можно не тестить"

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

Поэтому мы друг друга не понимаем.
Хотя здравое зерно есть.  
Но оно так зарыто, что экскаватором не разгребешь.

(417) Я с 1С разных версий с 1998 года работаю.
Прошел разные уровни - и франч, и фикси, и фри. Разных клиентов. Задачи разного уровня. Команды от 1 человека до 7.
В чем оторванность? в том, что говорю о простых примерах?
или в том, что занимаюсь тестированием? что еще?
Понимаешь, есть разные уровни. кто-то работает с ларьками и таких клиентов у него 20, кто-то работает над одной системой на фикси, кто-то работает в ит-конторе над кучей систем.
у каждого свой уровень, свои навыки, свои проблемы.
если тебе не нужно тестирование, ты или еще не дорос до этого или тебе это не нужно, потому что (подставь свои причины).

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

(414) в принципе, после [где ты увидел, что нужно делать "тестовые базы" под СКД? я лично писал, что данные нужно генерить, а не базы] тему про мантры тестирования СКД можно закрывать.

Остается только напомнить, что в силу архитектурных особенностей, данные, являющиеся входными для запросов и СКД, в 1С в отрыве от БД не существуют.
Самое неприятное, что иногда происходит реструктуризация.

И если вы думаете, что тестирование кода, связанного с обработкой данных персистентных хранилищ, — это проблема только 1С, то вы ошибаетесь.

(420) Это ты к чему?
(421) да, из-за особенностей 1С тестирование и тесты юзаются по-другому.
и что неприятного в реструктуризации?

(422) в том, что надо не только провести реструктуризацию тестовых баз, но и наборов для тестирования.

Наборов данных, конечно.

Или вы уже научились "генерить данные" в отрыве от БД?

(423) Да, тесты также нужно поддерживать.
Но не всегда это бывает сложно.
Например, в генераторе тестовых данных по макету и макета на базе реальных данных (из xUnitFor1C) сделано так: поля, у которых значение не отличается от значения по умолчанию (пустая ссылка, ложь, 0, "" и т.п.) не выводятся в макет.
в итоге макет проще и понятнее.
Да и достаточно редко добавляются реквизиты, которые обязательно должны быть заполнены.
А если новые реквизиты необязательны, то и старые макеты (и их тесты) не нужно менять.

(424) да, тут смешно получилось, я почему-то посчитал, что тебя сложность именно потому, что нужно много тест. баз зачем-то генерить :)

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

Попробуй, может быть, понравится :)

Пишу загрузку иксемеля
Файл иксемеля в имени имеет маркердаты
Внутри также есть дата
Макер в имени сделан для ускорения обработки и выборки файлов нужных из списка

Вопрос
Надо ли тестом предусматривать что маркер имени файла не совпадает с датой внутри файла?

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

(427) если обработка данных требует верификации, то надо ее делатьв обработке, а тест должен проверять верификацию: тест на корректные данные - верифкация прошла, тест на некорректны данные - верификация не прошла

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

(429)  вот загрузка иксемеля
Схемы нет
Надо ли проверять наличие суммындс в строке или нет? А хз!!!

(430) тестирование самого xml - дело твоей обработки, а тестирование кода, тестирующего xml, - дело тестов.

....а тестирование кода, тестирующего xml, - дело тестов....

Это ты сейчас действительно мощно выступил

Да есть понимание
Что требуется интсрументарий управления тестами
Автоматическим тестированием
Это голый инструментарий
Его освоим

Остались мутными вопросы собственно самой разработки через тестирование

(433) вот так всегда, управлять все хотят, а писать - код нет.

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

(435) не всегда. Когда точно знаешь, что должно получиться и какие шаги сделать, разработка через тестирование помогает.

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

Какое тестирование ?
Если вместо проверки работоспособности и правильности каждой функции делать проверку только всего алгоритма в целом, то потом можно на такие подводные камни нарваться, что мама не горюй.
Особенно, когда будет повторное использование функции - в ней окажется систематическая ошибка, которую не заметили из-за того, что весь алгоритм проверку прошёл.
А вот после исправления ошибки в функции - он будет работать неправильно.

В 1С, и в xUnit1c в частности, катастрофически не хватает простых конструкторов коллекций. Писать каждый раз Массив.Добавить() по 20 раз достает.

Демона нужно учить писать шаблоны в 1с? О_о

Еще в xUnit1c нет проверки на невхождение строки И сравнения коллекций

(439) у себя я пишу _ВМассив(1,2,3,4,5,6,7,8,9,10) и получаю что нужно

Еще могу написать _В(КакойТоМассив, "фывапролдж")
или так  _В(_В(_В(КакойТоМассив, "йцукен"), "фывапр"), "ячсми");
_В(КакаяТоСтруктура, "Ключ", "Значение")

(441) тяжело pull-request сделать?