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

Проблема достаточно многогранна, и сформулировать ее с первого раза мне, вряд ли, удастся. Но, тем не менее, с чего-то начнем.
Вобщем, суть проблемы. Для выполнения теста необходимо выполнить фазу, известную как setup, которая заключается в создании значительного количества различных данных в тестовой БД. В основном, это - создание элементов в куче справочников и заполнение кучи регистров начальными данными. Понятно, что есть тесты где этого не требуется, но речь не о таких случаях. И эта фаза меня сильно напрягает своей сложностью - всегда приходится морщить лоб, вспоминая какие виды данных нужно сгенерить, затем копипастить и редактировать кучу вызовов генераторв данных. Вобщем, эта фаза - наиболее трудоемкая при разработке теста.
При этом, специфика платформы 1С накладывает существенные ограничения на  использование существующих методик - они рассчитаны на "взрослые" языки программирования. Надо заметить, я ориентируюсь на 8, но и для 7.7 это не менее справедливо.

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

Это вкратце, для затравки. Если есть интерес к сабжу, если есть возражения или предложения, прошу отметиться в ветке. Флейм и оффтоп приветствуются тоже.

artbear
Обнадеживает, что проблема актуальна

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

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

Палыч писал(а) 07. Мая 2010 :: 07:21:


я сейчас (да и уже как месяца 4) тоже озадачен этой проблемой:

на ум помимо сериализации XML приходило :
1. храниться тестовые данные в формате YAML (fixtures)
2. хранить тестовые данные в виде 1С кода их создающего  

в любом случае необходимы либо:

1. реализация YAML для 1С и процедуры создания тестовых данных на основе YAML представления
2. генератор кода для создания объекта

вот такие вот бредовые пока идеи

artbear писал(а) 07. Мая 2010 :: 10:05:

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


lustin писал(а) 07. Мая 2010 :: 10:18:

А чем YAML лучше XML?


lustin писал(а) 07. Мая 2010 :: 10:18:

Звучит, пока, несколько фантастически. Реализовывать не планируешь?

Палыч писал(а) 11. Мая 2010 :: 08:04:


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

2. насчет генератора кода
- идея то была в свое время как раз придумана Федором (http://1c.alterplast.ru/exchange.html)
- как получившийся код выполнить через v8unpack и обработку-пустышку - было подсмотрено у tormozit в его ИнструментахРазработчика
- а насчет реализации - сказать труднее - кроме меня самого на текущих местах работы это и не надо никому - всем кнопочки подавай  . Ближайший месяц покажет... Кстати такую разработку надо однозначно через тестирование реализовывать 

Палыч писал(а) 11. Мая 2010 :: 08:04:

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

Ручная схема работы с использованием КД выглядит так:
1. в КД делаются правила для переноса данных. т.к. конфы практически одинаковые, то правила делаются совершенно элементарно, тыканием кнопочек.
2. Далее в КД получаем файл правил, который будет юзаться как при выгрузке, так и при загрузке данных в исходной (рабочая?) и конечной (пустая тестовая) базах.
3. в исходной (рабочей?) запускается спец.обработка, в которой и выбираются нужные объекты для выгрузки. Эта обработка создает спец.файл выгрузки в ХМЛ.
4. в конечной (пустая тестовая) базе с помощью спец.обработки загружается полученный ХМЛ-файл из п.3
ВСЕ - тестовые данные готовы
теперь осталось только автоматизировать этап загрузки (п.4) для использования в автоматических тестах.

Трудности - которые я вижу:
1. небольшие проблемы при изменении метаданных, но в КД все довольно просто меняется. нужно лишь не забывать об этом и вовремя менять правила.
2. ИМХО самое сложное - подбор всех нужных тестовых данных.
3. скорость загрузки может быть довольно слабой, хотя вряд ли сильно уступит варианту создания через кодогенератор.

Палыч писал(а) 11. Мая 2010 :: 09:21:

Не. Мне эти причины непонятны В 7.7 есть ++, в v8 есть возможность вызова экспортных методов. По крайней мере свои разработки можно (и нужно) писать с поправками на юниттестирование.

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

Цитата:

Считаю, что допустимо заполнить всю эту псевдостатическую информацию один раз. И проводить последующее автотестирование не на совсем пустой базе, а на хоть как-то первоначально заполненной.

fez писал(а) 11. Мая 2010 :: 11:51:

+1
ИМХО В 8-ке вполне удобно юзать юнит-тестирование, я в 77 не так активно применял юнит-тестирование, кроме разработки ++

fez писал(а) 11. Мая 2010 :: 11:51:

Прежде всего, считаю необходимым уточнить терминологию. Предлагаю пользоваться следующей классификацией видов и уровней тестирования, которая кажется  мне наиболее логически понятной:
http://protesting.ru/testing/testtypes.html
http://protesting.ru/testing/testlevels.html.

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

Цитата:

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

Цитата:

Во! Это уже по-существу! Как ты себе представляешь весь процесс при таком подходе?

Палыч писал(а) 12. Мая 2010 :: 07:10:

http://www.1cpp.ru/forum/YaBB.pl?num=1273770703

fez писал(а) 13. Мая 2010 :: 17:09:


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

Палыч писал(а) 14. Мая 2010 :: 06:54:

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

fez писал(а) 14. Мая 2010 :: 08:12:

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

Цитата:

Цитата:

[делаю вид, что не заметил эти тезисы] 

Цитата:

Ты уже, наверно, догадался, что я отвечу: скажу тебе больше, конечному потребителю платформы 1С  никакое тестирование вобще не нужно! 

И вобще, мне не совсем понятно, какую мысль ты хочешь донести? Что юниттестирование на 1С имеет право на жизнь? Дык я и не возражаю! 
Правда, при этом, возникает вопрос как ты тестируешь обеспечиваешь  (или предполагаешь в будущем) качество элементов конфигурации к которым платформа не дает доступа на уровне юнита? Тот же пресловутый документ, например?

Палыч писал(а) 14. Мая 2010 :: 09:06:

Не думал пока. Придумаю что-нибудь, когда дело дойдет

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

fez писал(а) 14. Мая 2010 :: 09:24:

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

fez
Понятно. На данный момент я использую аналогичный подход.

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

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

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

Может, я, просто, слишком ленив?

Прошу высказываться.

fez
Интересно было бы узнать подробности. Как собираешься использовать XML? Или уже не собираешься?

fez
Та-а-ак... Крайне любопытно
Насколько я понял, речь идет  о SnowTest. Так?
Какие данные ты планируешь хранить в базе-хранилище? Только базовые или более специальные?
Что содержит один хмл-файл? Один объект или целую пачку?

зы: и вобще вопросов еще масса...

fez писал(а) 02. Июня 2010 :: 07:05:

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

fez писал(а) 02. Июня 2010 :: 07:05:

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

artbear
В каком аспекте?
И я бы не рассматривал отчет как характерный пример для применения тестирования. Или тебя интересует именно отчет?

слегка OffTopic может быть:

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

но тут напоролся на описание: http://v8.1c.ru/expert/tc/tc_overview.htm

и возникла у меня очередная бредовая идея:

а нельзя ли этот тест-центр поиспользовать в качестве средства подготовки тестовых данных.

PS. Я все таки перебрался с семьей в Москву несмотря ни на что.

lustin писал(а) 10. Июня 2010 :: 07:24:


Когда я его смотрел, это было, наверно, с год назад, "сценарное тестирование" от 1С не производило впечатления инструмента для повседневного использования.
Ты уже посмотрел? Нашел что-то полезное?

и еще один хреновый момент связанный с тест центром

Цитата:


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

Чем больше я работаю тестировщиком - тем больше мне нравится программирование.

И чем больше я работаю с восьмёркой - тем больше мне нравится семёрка.

fez писал(а) 04. Июля 2011 :: 15:13:


Аналогично.

Давай, для начала, по второму.

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