0: Раз, раз, всем привет, давайте начистоту. Как часто у вас получается сразу начать тестировать свой код. Обычно сначала полчаса тратишь на подготовку тестовых данных, на проверку их, а потом

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

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

3: Меня зовут Станислав Баташов. Я работаю с 1 с более 13 лет. Сейчас я на позиции тимлида под группы разработки в компании озон. Пару лет назад я погрузился в юнит тестирование достаточно подробно и плотно и изучил, написал регламенты, документацию, обучил свою команду и

4: Сейчас делюсь экспертизой с вами и с соседними командами из нашего департамента. За это время я нашёл самый большой и проблемный Пласт в работе с юнит тестированием. Это подготовка тестовых данных. Оказалось, что написать тест это не проб.

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

6: Немного контекста о нашей системе это 1 из самых высоконагруженных баз в ozon её размер достигает 10 терабайт и более команда разработки, которая дорабатывает это 15 человек, конфигурация на обычных формах на основе управ.

7: Управление корпоративными финансами или укф, и у нас достаточно много интеграций это kafka, эйчтитипи, хранимые процедуры и деплоим мы это все и тестируем с помощью гиилаб ci давайте просто поговорим о приложениях приложения состоят из нескольких слоёв по заведомо.

8: Чистой архитектуры. Это пользовательский интерфейс бизнес, логика, слой доступа к данным. Ну и сама база данных в случае с 1 с тестированием нам помогает ванесса автомейшен для пользовательского интерфейса, для бизнес логики.

9: Unit для слоя доступа к данным и базе данных тестированием занимается сам вендор и эту часть мы не проверяем если говорить конкретно о юнит тестировании, то разбирая смысл unit Тестов на таком продукте как 1 с самое главное.

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

11: Мы их обрабатываем, перекладываем и вот эту вот логику перекладки, обрабатывания мы будем тестировать в рамках своих юниттестов. То есть мы должны убедиться, что преобразовании, логика работы над этими данными сохраняется. Если упрощает, то в других языках говорят, что просто убедиться в том,

12: Что перекладка из 1 джейсона в другой работает корректно.

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

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

15: Необходимости тиражируем базу. Это маленький Лёгкий продукт, который позволяет нам проводить какие-то дополнительные манипуляции с ней. Но давайте рассмотрим плюсы и минусы данного подхода из плюсов. Все актуальные процессы всегда в 1 месте. То есть это документация, это

16: Система, на которой можно гонять тесты, это демо, стенд, который можно использовать по назначениям, названным ранее. Это Лёгкая база, которую можно запускать как локально, так и на сервере. Ну и это полностью контролируемая среда команды разработки, либо там командой аналитико.

17: Кто занимается внесением, но есть и минусы. Это скорость актуализации данных. У вас появляется новый процесс. Аналитик бежит внедрять этот процесс, рассказывает про него пользователям, пишет документацию, и до этой базы дело может не дойти. То есть непонятно. Плюс ещё размазывается.

18: Ответственность, кто должен вносить эти данные разработчик, он не отвечает за процессы аналитик, но опять же, когда тестировщик, непонятно тоже по времени, когда и сколько нужно дополнять данных, а также это дорого. То есть это время на актуализацию, это время на удаление старых данных.

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

20: Использует небольшой объём данных, например, тот же экс юнит, про который сегодня я рассказываю. Там есть небольшая база, в которой содержится необходимая информация для тестирования продукта. В этом случае этот процесс может, этот подход может быть оправдан, но а если рассматривать с точки зрения разработчика,

21: Как я и сказал ранее, скорее всего, актуализацией данных будет заниматься не он. То есть для разработчика это 1 из идеальных вариантов. Он ничего не делает. Получает готовый продукт, на котором пишет юнит тесты и не тратит время на, ну, юниты интеграционные, не тратит время на подготовку этих данных. 2 вариант.

22: Который я хотел бы подсветить. Это та же копия продуктовой базы, про которую я рассказывал. Бэкапим, прод, разворачиваем на тестовом контуре нужное количество баз и запускаем тесты. У нас используется этот подход для части Тестов. У нас используются не актуальные копии, полноценные, а

23: Copy или copy on write для того, чтобы запускать там например дымовые тесты?

24: У копии продуктовой базы есть как плюсы и минусы. Это самая простая реализация. Каждый может это сделать, если у вас файловую дэтэшку скопировали, развернули. Если у вас скульная база, скопировали, опять же средствами Скуля и развернули, и все знают и умеют с этим работать. Также

25: Там же есть все необходимые данные, которые нужны фактически для Тестов. За актуализацией данных следит пользователь. Опять же, не разработчики аналитики, там все данные по актуальным процессам. Ну, ещё немного исторических из минусов этого подхода. Это подходит только для небольших баз, что я подразу

26: Зумеваю под небольшими базами. Наша база 10 терабайт, и она не самая большая. У коллег есть bass 92 терабайта, и развернуть достаточно быстро её для тестирования не очень получается. То есть есть определённые нюансы и ограничения. Также учётным данным нельзя доверять, что такое учётные данные, учётные данные.

27: Это данные, которые вводят пользователи и сопровождает саппорт, то есть команда сопровождения, которая может вносить нужные для бизнеса данные руками. Это ручные операции, какие-то обработки, которые не предусматривают работу с бизнес.

28: С логикой какие минусы у этого самое не самое плохое, что может произойти ваши тесты упадут с такими данными, а самое плохое тесты пройдут и покажут зелёный результат, то есть это будет ложно положительный результат, который пропустит ошибку в prod.

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

30: И пользователи могут внести туда чуть больше или чуть меньше. Ваши тесты будут падать, что создаёт дополнительные проблемы для разработчика. Опять же, с точки зрения разработчика, этот вариант самый простой. Он ничего не делает, он просто получает готовые данные, которые может переиспользовать.

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

32: Внесений там будь то специальный стенд или копия продуктовой базы. Данные можно создавать кодом, загрузкой из макетов или другими удобными для вас способами. Самое главное, чтобы данные были созданы в полном объёме, чтобы тест работал самостоятельно и как

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

34: Независимость от базы. Вы можете запустить это на специальном стенде, на копии прода, на пустой базе, потому что все данные вы создаёте руками во время работы. Ну и также версионируем сь тестовых данных. Если это market, если это код, вы можете это версионировать в гитлабе, либо в хранилище, если макеты прикладывать.

35: Непосредственно в свою конфигурацию, но у этого подхода есть и минусы. Это долгая подготовка тестовых данных. То есть нужно создать достаточно большое количество кода, либо подгрузить, либо выгрузить достаточно большое количество тестовых данных для того, чтобы работать с ними. Ну и

36: Code создания нужно поддерживать то есть это может быть Миграция, это может быть загрузка из макетов, какие-то изменения. То есть это достаточно трудоёмкая и долгая операция.

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

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

39: Для большой учётной системы подойдёт вариант с подготовкой тестовых данных на копии прода или, ну и генерация этих тестовых данных с помощью кода, ну или

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

41: Вероятность её крайне мала и не особо эффектит на результат Тестов для юниттестов библиотек как раз-таки эталонная база, и для юниттестов учётных систем это сочетание подходов бэкап и создание тестовых данных тестовых данных с помощью

42: Обсудим инструменты для упрощения работы с тестовыми данными как же упростить работу с тестовыми данными для разработчика 1 вариант это использование выгрузок данных самый простой инструмент универсальный обмен данных в формате xml.

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

44: Специально для Тестов подойдёт для этого выгружаете выгружаете тестовые данные в эксемель джейсон прикладываете их к тестам можно сделать зависимости можно сложить их в gitlab там же хранить либо опять же в тестовое расширение выгружается необходимый минимум.

45: Информации, необходимой для теста, то есть это могут быть inc какие-то настройки, документы или вообще состояние системы на нужный вам момент, но есть вопросы, которые необходимо решить это где хранить выгруженные данные это опять же gitlab хранилище расширение это нужно вам решить самостоятельно.

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

47: Этих данных в выгруженных макетах, ну и плюсы, и минусы данного подхода. Давайте разберём. Это простой и понятный инструмент. В принципе, он есть у всех, у кого есть интеграция. То есть вы можете использовать уже существующий инструментарий, который у вас имеется. Также данные можно

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

49: Может затрачиваться много времени также ошибся выгрузил половину базы это отсылка на универсальный обмен в формате xml потому что он достаточно удобный и инструмент который имеется у всех ну и сложная структура данных при выгрузке в ту же эксемель нельзя зайти в gitlab, например.

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

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

52: Если база маленькая, это приемлемо. Если база большая, тратится большое количество времени, там от нескольких часов до, там целых дней. 2 вариант, который я предлагаю, это хранение данных в коде метаданных. Этот вариант как раз-таки самый предпочтительный. Он использует механизм.

53: Фреймворка екс юнит и позволяет создавать тестовые данные во время Тестов или перед ними, а также эти данные будут удаляться после выполнения самих Тестов. Все это позволяет делать фреймворки из коробки. Ну и давайте разберём варианты тут на са.

54: На самом деле не особо видно код, но важно понимать просто про количество строк код можно потом посмотреть подробнее в презентации здесь паттерн триплей это подготовка, действие i проверка в начале мы пишем как

55: Вообще выглядит алгоритм написания теста. Мы пишем какую-то рыбу, пишем 2 часть, это проверка и пишем 3 часть.

56: Пишем 3 часть подготовкой проверки ожида с проверкой ожиданий.

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

58: Времени. Дальше мы готовим. Дальше мы пытаемся разобраться, что же происходит дальше. Пишем ещё 1 код подготовки тестовых данных. Поняли, что не подготовили начальные остатки. Код подготовки остатков выглядит следующим образом.

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

60: Звучать просто, то есть если у вас много легаси, где не соблюдались стандарты разработки, а также здравый смысл плюс разработчики приходили из разных компаний и так далее. У вас может быть достаточно путанный и сложный код и на расследование

61: Откуда берутся тестовые данные и какие настройки нужно сделать. Может уйти достаточно большое количество времени. Ну и разберём плюсы и минусы данного подхода. Помимо того, что я описал с подготовкой самого кода теста плюсы, хранение в коде

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

63: Макеты, которые часто используются, опять же с форматами вашей компании. То, что используется у вас. И там, например, табличный документ можно раскрасить, подкрасить какие-то ячейки, которые необходимо будет использовать разработчику в своей работе.

64: Также создавать все данные необязательно. Екс юнит позволяет создавать не все данные, позволяет создавать фикции объектов, то есть с помощью определённых настроек, либо руками вы указываете, какие реквизиты создаются фикционного, не нужно их предзаполнять и тратить.

65: Большое количество времени, то есть для конкретной какой-то тестируемой операции вы пишите код создания тестовых данных, делаете какие-то реквизиты, которые необязательно для неё фекционными и все. То есть фреймворк сам создаст ссылки, заполнит и от вас ничего не будет требоваться. Ну и

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

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

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

69: Использование скриптов для загрузки таблиц данных на уровне субд. Вариант, запрещённый лицензионным соглашением компанией 1 с. И который, соответственно, не приветствуется вендором из плюсов данного подхода. Это быстрая загрузка данных. Просто написали скрипт, выгрузили данные.

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

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

72: Я просто подсвечиваю возможные варианты. Ну и он не рекомендуется к использованию по названным ранее причинам.

73: Ну и сделаем выводы.

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

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

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

77: Работы с тестовыми данными это модули помощники, как они называются в документации по факту это общие модули, в которых лежат какие-то атомарные методы по работе и созданию тестовых данных. Это общие модули, наполненные именно наполненные нужным функции.

78: Analogue для разработчиков, который можно переиспользовать при создании тестовых данных.

79: Это пример нашего модуля помощника. Здесь можно заметить достаточно большой объём процедур функций. Они в основном направлены на специфику того блока учёта, который мы автоматизируем. Это именно финансовый учёт. Там в дальнейшем посмотрите, если вам будет интересно.

80: Какие-то принципы, какие принципы мы преследуем по работе с модулями, помощниками. Методы должны быть универсальными, а не узкоспециализированными. То есть все методы должны быть атомарными, либо такими, чтобы можно было их переиспользовать как детали конструктора. Смысл создать

81: Важные и нужные инструменты для разработчика и а не складывать туда все подряд, что вы подумали, что может вам пригодиться. Методы должны возвращать готовые объекты или конструкторы, которые можно переиспользовать, заполнить и

82: И также использовать как детали конструктора. Они должны быть атомарными, чтобы их опять же переиспользовать. Примеры, примеры таких методов. Это метод создаёт готовый объект и возвращает, возвращает сам объект или ссылку по параметру.

83: Либо создаёт предзаполненный конструктор объекта и возвращает его для дальнейшего заполнения. Плюс можно как-то заполнять настройки, например, создать учётную политику для организации с возможностью кастомизации по параметрам. Ну и методы должны быть

84: Документированы. Разработчик не должен тратить время на то, чтобы погружаться в детали этого метода. Просто прочитать документацию должно быть достаточно. Ну и приведу несколько примеров. Это, например, создание справочника организации. Метод параметризирован и

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

86: На осмысление работы этого метода, что позволяет создавать нужные данные в нужном виде для разработчика. Пример функции для регистра. В этом случае это учётная политика. Сам функционал достаточно большой. На самом деле это просто копия учётной политики по нашей основной

87: Организации с возможностью дозаполнить её или кастомизировать из параметров, которые передаются с

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

89: Основе обработки по созданию данных выглядит он следующим образом. Это обработка, которая создаёт не только тестовые данные, но и просто данные для работы, для обработчиков обновления или для каких-то других ваших целей выглядит

90: Следующим образом имеет 2 области область по выбору элементов и также область по со сгенерированным кодом. Здесь выбираются какие-то элементы, которые вам необходимы на вкладке. Код по значению. Нажимается кнопка сформировать код и разработчик.

91: Получает готовый код, также поддерживается 2 вариант работы. Это работа с конструктором движений. Здесь выбирается элемент справочника оо элемент, здесь выбирается документ, выбирается движение, которое нужно

92: Сгенерировать в код, и они выводятся опять же разработчику из минусов, которые я подчеркнул для себя, так как мы стараемся создавать фиктивные объекты, а не переиспользовать существующие в конфигурации. Здесь этого функционала нет, здесь генери.

93: Код, который использует существующие объекты конфигурации по там найти по наименованию, найти по коду или предопределённые. И поэтому для нас это не самый удобный инструмент, но в своей работе мы используем вот этот инструмент помощник для создания тестовых данных.

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

95: Создание кода генерации движения документа и создание кода генерации самого документа. То есть те кейсы, которые мы старались автоматизировать, это проверка проведения документа, и, соответственно, её создаётся результатом работы этой обработки будет код по созда,

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

97: Как-то кастомизировать, что-то поменять, но это помогает разработчику с тем, что большая часть кода уже написана и её нужно только поменять, а не писать с нуля. Ну и

98: Необходимые для создания тестового объекта данные должны генерироваться, а не искаться в базе данных, но этот подход немного поменялся. Дальше расскажу, каким образом и что из этого вышло. Интерфейс выглядит.

99: Примерно похоже на генератор. Здесь есть 2 режима. 1 режим это работы с формированием кода для конструктора объекта. 2 вариант это код для конструктора движений. Начнём с кода. Для конструктора объекта указывается ссылка, указывается дополни

100: Настройки, которые находятся там же, это использовать макеты табличных частей или нет. Это инлайн макеты, которые дальше покажу, как работают. Есть несколько режимов выгрузки макетов движений, то есть хранить можно в табличных частях, в текстовом макете, в формате markdown и в инлайн макет.

101: Непосредственно в коде, ну и также выбираются те движения, которые есть у конкретного объекта. Здесь заполняются не все данные по регистрам, которые есть у документа, а только те, которые заполнены у конкретного экземпляра, который вы выбрали.

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

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

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

105: Ничего сложного. Есть там 4 процедуры, которые используются для переопределения.

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

107: И искать эти объекты уже в непосредственно базе, чтоб не тратить время на создание этих тестовых данных. Ну и мы видим, что использование переопределяемые предопределённых значений, которые используют функцию предопределённое значение с текстовым представлением элемента,

108: Ну и ещё 1 вариант работы с тестовыми данными, который является основным. Это создание элементов с помощью механизмов фреймворка. То есть генерируется код, который создаёт элемент по типу данных и подставляет его значение в переменную. Зачем нам нужны переменные, можно увидеть уже

109: На следующем слайде, то есть это линейное заполне, это заполнение линейных реквизитов объекта.

110: Здесь можно увидеть вариант заполнения реквизитов с помощью кода, который, опять же в том же модуле тестовых данных, переопределяемый используется, ну и, соответственно, можно увидеть заполнение с помощью реквизитов, примитив, значение реквизитов значениями примитивных типов.

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

112: Макетов, и если используется режим работы с табличными частями в виде онлайн макетов, то эти заменяемые значения подставляются туда, и данные из макета загружаются уже согласно тем данным, которые указаны здесь в

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

114: Образом. Если у вас небольшое количество табличных строк в табличных частях, то можно загрузить с помощью кода. Оно наглядно и понятно. Но если у вас большое количество строк в табличной части, то я рекомендую использовать заполнение табличной части из макета на 1 строке. Это выглядит так.

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

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

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

118: Здесь есть код модуля обработки, который, листинг которого выглядит следующим образом, выглядит точно так же, как загрузка самих табличных частей в 1 части это определение типов полей макетов, дальше идёт создание соответствия.

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

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

121: Грузки из макета. Ну и 2 вариант работы это текстовый макет, который выглядит вот следующим образом.

122: Ну и 3 вариант, который, как и раньше, я рассказывал при загрузке из онлайн макетов.

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

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

125: Сгенерированный код выглядит более лаконично. Это весь код. То есть в 1 части у нас определяются переменные. Во 2 части у нас заполняется строка регистра в данном случае реализации товаров и услуг и

126: Регистр, журнал учёта счетов, фактур, ну и тот же код по работе с онлайн макетами выглядит он примерно так же, но область переменная.

127: И вот эта вот область по загрузке из макета, тут есть заменяемые значения, здесь определение типов, соответственно, сам макет и код загрузки. Вот здесь вот. И вот запись уже вот здесь. То есть этот код, опять же, предполагается для того, чтобы загру

128: Какие-то большие таблицы он будет чуть меньше места занимать, чем предыдущий вариант, ну и подведём итоги.

129: Какой же лучший способ по работе с тестовыми данными, который я порекомендую никакой. Выбирайте самый подходящий и самый нужный для вас, для конкретных целей. То есть вы определяете цели и определяетесь с инструментами. Я могу лишь посоветовать вам и рассказать то, что было на моём

130: Лучший вариант для создания тестовых данных, опять же тот, который подходит вам под ситуацию.

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

132: И спасибо за внимание.

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

134: 2 микрофона и, пожалуйста, вопросы в микрофон, потому что ещё онлайн есть. Стас, спасибо за доклад. Все здорово. Хочу задать такой вопрос. Как известно, больше всего времени при тестировании тратится на запись в базу и вообще в 1 с так.

135: Что это самое проблемное место, узкое горлышко. Так вот, поэтому в большинстве Языков других разработчики в модульных тестах вообще ничего в базу не пишут, соответственно, ограничиваются моками, заглушками, а вот эту часть за

136: Данных с тестированием сценариев они передают на сценарные тесты, то есть, может быть делать моки заглушки, а сценарное тестирование как бы будет заниматься записью данных, можно использовать и smokie заглушк.

137: Можно использовать методику создания тестовых данных перед непосредственно набором Тестов, то есть уменьшать время на создание при работе с самим тестовым набором.

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

139: Тесты на проведение того же документа, поэтому в нашем случае это необходимая трата времени. Все зависит от целей. Я немножко дополню, мне нравится классификация егора Бугаенко, наверное, слышали, когда слушаете, у него есть все тесты, делятся на fast и deep.

140: То есть если вам надо быстро что-то проверить у вас быстрые тесты, вы их тегами помечаете, запускаете вы как smokie, тогда там все изоляция, если нужно глубоко протестировать сильно, то соответственно deep тесты тегами их отдельно отдельно гоняются, то есть такой подход наверное.

141: Рабочий такой практичный, полезный. Ещё вопросы?

142: Неожиданно Стас там был вопрос есть ли твой помощник вообще где-то скачать его можно da забыл подсказать на данный момент он законтрибьютим непосредственно в якс юнит и со следующим релизом он будет доступен. То есть это

143: Помощник можно использовать и посмотреть самостоятельно.

144: Добрый день. Добрый. Спасибо большое, кстати, за хороший вклад в опенсорс в этот проект очень классный. Подскажите, пожалуйста, я, честно, очень глубоко не погружался, так как разработчик тестировщик к тестировке очень поверхностно подошёл.

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

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

147: Там справочники. Каким образом можно сделать хорошую выборку, чтобы минимизировать объём данных. Тут вопрос. Нужно ли вам это покрывать юни тестами интеграционными и может быть лучше все же сценарными, потому что подготовка тест

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

149: Тестировать расчет себестоимости, то есть достаточно сложно и объёмно. А надо ли тратить на это время? Есть другие варианты. Спасибо большое. Да, универсального решения нет. Нужно комбинацию использовать. Вот подходов всех перечисленных на практике в зависимости от кейса.

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

151: У нас ещё есть время на вопросы.

152: Все загрузились, все переваривают информацию.

153: Хорошо, да, тогда встретимся в кулуарах, наверное, уточним. Да, подходите, если есть вопросы, и на круглом столе завтр.