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

(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 сделать?