Как быстро развернуть автоматическую линию проверки своего решения на 1С, затратив 8 часов и получив выигрыш в 1 человеко/месяц

Я расскажу о том, как запустить тестирование, и покажу, что это несложно.

Начну с проблематики – какие есть потребности у разработчиков, у команды 1С, у компании?

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

• Хочется внедрить автотесты, статический анализ кода, применить код-ревью. Ничего этого пока нет, а хочется, чтобы все это заработало.

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

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

• И вообще ускорить бы выпуск решений/доработок – чтобы результат получался быстро.

Есть проблемы:

• Кажется, что это сложно, что это магия.

• Мы ничего об этом не знаем.

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

• Информации много, но непонятно, с чего начать, у кого спросить.

• Даже если мы начнем это делать – кто это будет сопровождать? Тот ли человек, который запускал, или какой-то другой?

Уйма вопросов.

Необходимые условия для фонового внедрения тестирования

На самом деле все очень просто.

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

Пусть команда 1С работает, как раньше:

• если использовали хранилище – используют хранилище 1С;

• работают с внешними файлами как угодно – через Git или не через Git – без разницы;

• разработка ведется по текущим шаблонам – в конфигураторе создаете внешние обработки, печатные формы. Все, как обычно, ничего не меняется.

И где-то рядом проводится «фоновое» внедрение. Его проводит кто-то один. Ему выделяется отдельный сервер либо так называемый «сервер сборок под столом» – можно просто взять свою же машину. И на этой машине разворачиваются все необходимые инструменты.

В роли того, кто будет выполнять указанное внедрение, может выступать разработчик 1С или администратор. Этому человеку достаточно просто уметь работать с командной строкой Windows. Linux мы пока не используем, потому что это сложно – для этого нужны дополнительные знания, это не все умеют, это уже будет второй этап.

Какие инструменты нужны? Повторюсь, что здесь все достаточно штатно:

• наш любимый конфигуратор платформы 1С:Предприятие;

• инструменты от 1С – ras / rac / ring;

• также можно использовать известные инструменты не из мира 1С – наверняка многие слышали про Allure, про Java и т.д.

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

Для OneScript очень много готовых библиотек, практически все они развиваются как OpenSource-продукты – на слайде я привел несколько самых популярных.

Инструменты есть, они проверены – нужно только их запустить и настроить.

Расскажу про инфраструктуру, которая требуется для базового внедрения.

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

• Git-сервер – на слайде приведен список. Здесь самые разные серверы. И от Microsoft, и от GitLab, BitBucket, GitHub и т.д.

• Сервер CI/CD – тоже любые серверы, я их специально перечислил.

• Task-tracker – здесь может быть Jira, тот же GitLab и т.д.

• В качестве сервера приложений – наш любимый 1С

• И для удобного код-ревью тоже инструменты есть.

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

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

Примеры из моего опыта:

• запуск в большой компании из тройки федеральных сотовых операторов;

• внедрение в небольших компаниях;

• обучение запуска физлиц, которые посещают наши практикумы - разработчики\аналитика\тестировщики обучаются.

Первый этап практически всегда одинаковый.

• Цель - быстро запуститься.

• Берем свою машину или уже существующий сервер. Другое название такой машины – «ночной сервер сборок», когда весь набор инструментов автоматически запускается, например, ночью, или когда у вас машина свободна\простаивает, тот же пример с ночью.

Как запускаем:

• Если в компании есть CI-сервер, его можно использовать, Например, запустить или переиспользовать выделенный сервер Jenkins, GitLab, Microsoft Azure DevOps и т.д. Идеально, если рядом есть специалисты, которые могут настроить этот сервер, могут помочь в настройке или выдать вам права на сервер для начала. Но помощь стороннего сотрудника может быть получена не сразу, что мешает быстрому запуску.

• Самый легкий способ запуска заданий на первом этапе, если используется своя машина или выделенный сервер – это банальный планировщик Windows. На начальном этапе вам даже не нужны права администратора.

• Просто используем штатную возможность Windows - запуск приложений из командной строки.

8 часов на внедрение автоматизированных проверок

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

• Как всегда, нужен небольшой объем первичной подготовки ПО – 1 час.

• Статический анализ кода – 0.5 час.

• Дымовые тесты – 2.5 часа.

• Потом делаем синхронизацию хранилища 1С с Git – 2.5 часа.

• И настройку – 2 часа.

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

Статический анализ кода

С чего нужно начать?

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

• базовая синтаксическая проверка конфигуратора;

• и обязательно нужно использовать “расширенную” проверку.

Что такое расширенная проверка? Я проводил много обучений с компаниями, с физлицами, и выяснил, что не очень много коллег знает, что в 1С давненько уже есть так называемая “расширенная” проверка, которая позволяет проверить вызовы через точку. Например:

• если есть обращение к объекту, и у него вызывается некий метод или идет обращение к его свойству.

• 1С может проверить подобный вызов для простого объекта или общего модуля.

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

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

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

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

Чтобы запускать чаще, используем:

• инструмент Vanessa-runner. В нем есть специальная команда syntax-check, которая выполняет проверку из конфигуратора с помощью пакетного запуска конфигуратора. Абсолютно штатно – все через 1С.

• Далее результаты проверки можно посмотреть через инструмент Allure. Инструмент достаточно известен. Ребята, которые его придумали, ранее работали в Яндексе, но сейчас это отдельная команда.

Итак, из командной строки запускаем команду

vrunner syntax-check

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

Повторюсь про внедрение в фоновом режиме. Мы запускаем проверку на отдельной машине и затем изучаем результаты.

На текущем слайде показано, как синтаксическая проверка работает уже на настоящем сервере CI/CD - на примере выделенного Microsoft TFS у одного из клиентов.

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

Дымовые тесты

Следующее, что нужно сделать – запустить так называемые “дымовые” тесты.

Дымовые тесты проверяют рутинные операции 1С:

• Открытие, закрытие форм.

• Перезапись элементов, создание документов, перезапись существующего документа.

• Командный интерфейс и т.д.

• Есть тесты ввода на основании документов, элементов справочников.

• Есть проверка схем СКД – если у нас есть какие-то отчеты, в них есть свои схемы СКД, мы можем сразу проверить – валидные ли запросы в этой схеме, вообще схема валидна? Может быть, в схеме используются устаревшие метаданные или есть реквизит метаданного, которого был удален или переименован.

  • Для поиска указанных проблем была написана простая проверка, которая перебирает все метаданные, находит у них все макеты с типом «Схема компоновки данных» и пытается скомпилировать эту схему СКД. Если неудача при компиляции, тогда выдается ошибка с текстом, который возвращает 1С.

• Есть тесты печатных форм.

Все это есть в инструменте Vanessa-ADD, дымовых тестов очень много, они развиваются и постоянно добавляются.

Буквально вчера (“вчера” от даты выступления в 2020г.) я случайно узнал, как дымовые тесты проверки командного интерфейса из Vanessa-ADD доработала команда УНФ из фирмы «1С». Коллеги сделали прикольную вещь – открывается форма списка и выполняется перезапись двух элементов из списка. Сначала в форме списка (например, справочника или документа) открывается первый элемент и записывается, а потом идет переход к последнему элементу и тоже перезаписывается. Получилась полезная проверка.

Для запуска дымовых тестов помимо конфигуратора 1С нужны инструменты:

• Vanessa-ADD;

• Vanessa-runner, который позволяет запускать тесты из командной строки

• И Allure, который показывает результат.

Команда запуска:

vrunner xunit

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

На слайде показан пример типового отчета Allure по запуску дымовых тестов на БСП.

Как видно, выполнено достаточно много тестов – 1200. Видны результаты тестов, количество и процентовка ошибок.

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

На слайде еще пример на более серьезной системе – это самописная конфигурация на базе ERP или Управление Холдингом, точно уже не помню.

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

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

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

• Слева – набор шагов, который нужно сделать.

• Справа – это результат тестирования.

В данном случае сработало всего сто девяносто три теста, и один тест упал – искусственно было добавлено исключение для примера.

Версионный контроль Git

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

• Все знают про хранилище 1С. Все знают, что оно не очень удобное, не очень быстрое и т.д.

• Наверное, уже многие знают, что есть система версионного контроля Git.

• И есть инструмент, который позволяет переносить историю хранилища 1С в Git-репозиторий (в систему Git) – это GitSync.

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

• Сможем интегрировать наше хранилище и трекер задач (ту же Jira, Битрикс, GitLab и т.д.).

  • Важно ввести в привычку себе и своим коллегам в команде, что нужно указывать номера задач в формате #НомерЗадачи. В Jira обычно формат #НомерПроекта-НомерЗадачи. На GitLab и GitHub – строка #НомерЗадачи. Когда мы помещаем изменения в хранилище 1С, мы пишем текст, потом на новой строке или в этой же строке #НомерЗадачи.

Интеграция с этими системами появится после того, как GitSync сделает синхронизацию по команде.

gitsync sync

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

После того, как мы выложили свой код в Git , начинает работать остальная магия – можно запускать всякие CI/CD сервера непрерывной интеграции, можно запускать статический анализ кода – SonarQube и т.д. Дальше появляется очень много возможностей для улучшения - становятся доступными инструменты код-ревью и другие механизмы, основанные на доступных исходниках в Git.

Фирма «1С» придумала свой инструмент GitConverter для синхронизаци хранилища и Git. Инструмент работает исключительно с 1С и внутри 1С. А GitSync работает как инструмент командной строки. Оба подхода имеют право на жизнь, но мне больше нравится GitSync. Я активно участвовал в его доработке, сейчас уже выпущено третье поколение, инструмент активно развивается.

На слайде приведен пример той самой магии – связь задач с исходниками в коде.

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

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

Чек-лист выполнения

Давайте закрепим, что нужно:

• Подготовка – мы должны установить ПО – поставить OneScript, Allure, выбрать какую-то базу 1С, если у нас еще ее нет – клиент-серверную или файловую. Эта настройка может занять 1 час

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

• Дымовые тесты мы запускаем командой vrunner xunit.

• Синхронизацию хранилища 1С и Git мы делаем через команду gitsync sync (для версии 3.0) или команды gitsync export (для версии 2.0).

• Если у вас нет сервера CI, выполнение по расписанию можно просто настроить через планировщик Windows. Если сервер есть, на сервере CI можно настроить расписание или триггер запуска – повторюсь в очередной раз, что нам нужен запуск из командной строки указанных ранее команд.

Если вместе сложить время этих действий, суммарно займем примерно 8 часов. Это настоящие цифры, на своих практикумах я коллегам как раз и показываю, что все реально – мы на занятиях полностью в это время укладываемся. Единственное, на практикумах мы не делаем синхронизацию хранилища, а сразу же учимся еще и BDD.

Результаты

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

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

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

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

• Всего 1787 простых дымовых тестов.

• Примерно посчитали, что по четыре проверки на каждый справочник/документ.

• Прикинули, что в идеальном случае каждая проверка делается вручную за одну минуту.

• Простая математика – если на ручное тестирование в команде разработки выделен специальный человек, который делает это раз в две недели, минимальные затраты на ручное тестирование – 60 часов.

Дальше – синтаксическая проверка.

• Расширенная синтаксическая проверка на конфигурации УТ 11 выполняется примерно 20 минут.

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

• На каждый коммит желательно выполнять полный синтакс-контроль в виде расширенной проверки.

• Опять же, простая математика – 15*20 = 300 минут, это 5 часов в день.

• Получаем, что только на синтаксической проверке, при минимуме коммитов, для команды из 15 человек получалось бы 100 часов затрат времени в месяц.

Складываем оба полученных числа, получаем 160 часов.

Вывод - когда мы автоматизировали перечисленные ранее проверки, мы сэкономили 160 часов – целый человеко-месяц. Только за счет того, что запустили простейшие операции – дымовые тесты и синтаксическую проверку.

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

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

Удалось ли решить проблемы?

Помните, с чего все начиналось? Очень сложно, магия, не понятно – где, что, как…

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

• Инструменты все известны, список есть, и они давно уже используются.

• По времени также все очевидно – затраты небольшие, получена экономия. Цифры вы сами видели.

• С чего начать – ответ элементарен. Чек-листы есть, инструменты есть. Конечно, это OpenSource-инструменты, поэтому там с документацией не всегда хорошо. Но документация меняется, дорабатывается, инструменты дополняются – появляются новые тесты, например, и так далее.

• Можно спросить, найти того, кто поможет и будет сопровождать – все в наличии. Есть Инфостарт, Telegram, GitHub, где вопросы использования активно обсуждаются.

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

Что дальше

А дальше уже переход к следующей магии:

• Нужно начинать использовать инструменты для проверки непосредственно на сервере CI/CD (сервер CI – это сервер непрерывной интеграции, а сервер CD – это сервер непрерывной доставки):

  • Vanessa-Runner – это все операции пакетного запуска из конфигуратора со всякими полезными возможностями.

  • Packman – это инструмент на OneScript, который позволяет создавать файл поставки.

• Инструменты приемочного тестирования BDD – повторюсь про Vanessa-ADD на языке Gherkin или продукты-соседи (Vanessa Automation, Тестер). Недавно на одном из мастер-классов коллега предложил вариант Гренкин – мне нравится, я теперь частенько его употребляю.

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

• Дальше – статический анализ кода, SonarQube, BSL Language Server, который проверяет наш код на правильность.

• И есть Docker, параллельный запуск тестов, нагрузочное тестирование и т.д. и т.п.

Вопросы

Я думаю, что у многих есть проблема, что тесты-то написать можно – можно придумать, как проверять, а что делать с тестовыми данными? Когда разработчик пилит какую-то фичу, он должен создать макеты данных? Можно ли запускать тесты на рабочей копии? Или для этого лучше использовать какую-то обрезанную базу? Многие разработчики говорят: «Мне что, еще и макеты данных пилить? Нет, дайте мне копию, я там проверю все». Как вот это организовать?

Да, когда мы начинаем писать свои настоящие тесты – приемочные, интеграционные – проблема данных стоит очень остро. Самый простой путь, с чего лучше начать – берем некую эталонную базу. В качестве эталонной базы может выступать копия рабочей, но ее данные не должны меняться – мы копию берем один раз, и она должна быть долгоиграющей. Мы используем эту копию как эталонную. Мы не восстанавливаем эталонную базу из рабочей каждый день или с подобной частотой. Мы эталонную базу только выгружаем в тестовую базу и обновляем конфигурацию в этой ИБ. Крайне желательно, чтобы эталонная база не была такого же объема, как и рабочая. В рабочей базе могут быть терабайты данных, попробуйте у разработчика такое развернуть.Лучше всего очистить эталонную базу, убрать какие-то переполненные регистры, присоединенные файлы, убрать какие-то наборы документов, которые для тестов не нужны.

В эталонной базе должно остаться некое состояние – вся НСИ и документы прихода, расхода, какие-то регистры, остатки, итоги и т.д. Чтобы мы четко понимали, что эти данные в тестах всегда будут одинаковы, и тест сможет на них рассчитывать. Например, тест может номенклатуру не создавать, а четко знать, что эта номенклатура всегда есть. У нее всегда нужное исходное состояние, есть остатки по этой номенклатуре – можно ее продать, оприходовать и т.д. Это один из вариантов.

Еще можно добавлять данные через те самые макеты. В Vanessa-ADD есть инструмент – “Генератор макетов данных”, который был сделан специально для быстрого добавления данных в эталонную базу. Если мы встретили какой-то баг в рабочей базе, с помощью генератора данных мы быстро можем состояние данных для этого бага сериализовать в табличный документ. И потом восстановить на эталонной базе. И далее на этих же данных на своей базе проверить поведение, сделать тест и доработать код системы.

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

Это сложная холиварная тема. Очень часто все-таки лучше взять эталонную базу. Всегда проще часть НСИ держать в ней, чем каждый раз заморачиваться с догрузкой данных. Можно сделать некий инструмент для управления, но зачем? Во-первых, у нас есть некий тест, который проверяет некий сценарий. Пусть этот тест будет самодостаточным. Надо четко понимать, что тесту нужны такие-то данные. Зачем знать или помнить, что какие-то другие тесты используют эти же данные? Пусть используют независимо друг от друга. Вопрос актуализации данных легко решается через штатные обработчики обновления – системные, БСП-шные. Когда мы переходим на новую версию своей системы, мы можем автоматически данные догрузить, обновить реквизиты, мигрировать и т.д.

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

Вся сила дымовых тестов в том, что их не нужно писать. Эти тесты существуют. Вам, как разработчику, не нужно писать тесты. Берите готовые. Сегодня (на время выступления в 2020г.) мне один коллега сообщил, что у него в компании ребята были очень рады дымовым, потому что это сразу дает несколько тысяч готовых тестов «из коробки», они рады экономии времени и приносимой пользе. Тесты на открытие форм развиваются уже порядка пяти лет. Недавно появились тесты командного интерфейса. В прошлом году появились тесты проверки СКД.

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

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

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

Где взять дымовые тесты?

Все дымовые тесты находятся в каталоге tests продукта Vanessa-ADD.

Есть ли готовые тесты для 1С:ERP?

Да, у команды разработки 1С:ERP есть тесты, не все их тесты опубликованы. У коллег свои сценарии под собственные требования. Вся проблема тестов в том, что тесты, которые делает кто-то, те же самые дымовые тесты, подходят только под определенные сценарии. Например, под рутинные операции – открыл/закрыл форму. Если вы внутри заполняете какие-то поля, проводите как-то документ, формируете печатную форму, то есть добавляете собственную логику, вы должны самостоятельно написать некий приемочный тест, который должен знать, что на выходе, как ему проверить ту же самую печатную форму, какие поля в ней правильно заполнены, а какие неправильно.

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

Необязательно. Есть дымовые тесты, которые пытаются перезаписать элементы или создать какой-то новый элемент – тесты открытия формы и т.д. Если у вас по умолчанию в базе есть типовой справочник «Номенклатура» – нельзя создать пустой элемент справочника, 1С просто не даст записать. Если вы заполните только наименование, ваш тест упадет. Другие тесты также упадут, потому что не заполнены обязательные поля. Нужно либо исключить этот тест из работы, либо сделать так, чтобы эта формы элемента номенклатуры заполнялась определенными пред-заполненными полями. Это можно сделать через файл настройки. Два варианта – либо исключаем форму из тестирования, либо добавляем настройку, чтобы такие формы создавались.

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

Разработка дымовых тестов для своей конфигурации входит в 2.5 часа или это время только на то, чтобы инфраструктуру развернуть?

Конечно, разработка тестов в указанное время не входит, потому что дымовые тесты писать не нужно, они уже написаны и входят в поставку Vanessa-ADD.

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

При ответе на этот вопрос нужно идти от потребности. Бизнес хочет, чтобы система, за которую он заплатил команде разработки, работала. Как команда разработки достигнет указанной цели, бизнесу все равно. Бизнес в большинстве случаев не хочет дополнительно платить. А команда разработки может достичь качественный результат разными способами. Один из способов – использовать статический анализ кода. В EDT, в конфигураторе. Я ранее привел пример – синтаксическая проверка тоже часть таких ошибок ловит. В EDT будет чуть лучше ловить, но без гарантии, потому что в EDT разработчик может убрать эту галочку – эта расширенная проверка в EDT также не особо быстро работает. И в итоге – проверка-то есть, но мы ей не пользуемся. И нужно каким-то образом закрыть потребность, чтобы проверка выполнялась. Для этого служит периодический запуск и расширенной проверки синтаксиса из конфигуратора, и автоматические тесты и статический анализ кода (через SonarQube, через EDT и т.д.) . Чем чаще мы ими пользуемся, тем меньше шансов у бага проскочить.

К сожалению, есть еще такая аксиома: «Никакие методики тестирования, статический анализ кода не найдут все ошибки». Об этом нужно просто помнить а начинающие коллеги частенько забывают. Вы можете сделать много действий, но ошибка все равно может проскочить. Ошибки могут появляться – это нормально. Но разработчик-профессионал обязан сделать так, чтобы после исправления баг никогда больше не появился.

*************

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Ekaterinburg.Online.