Механизмы тестирования в 1С. Использование методики TDD (разработка через тестирование) в 1С

09.02.15

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

Основные этапы разработки в 1С

Проектирование
Кодирование
Тестирование
Отладка

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

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

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

Дальше идет поиск ошибок, отладка.

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

Есть такой закон, который я, например, прочитал у Макконелла – Главный закон качества ПО:

Повышение качества программного обеспечения снижает затраты на разработку и сопровождение системы.

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

Пример правильности этого закона: Отладка и исправление неверного кода занимает около 50 % времени. То есть – 50 % времени всей разработки мы тратим на поиск ошибок.

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

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

Методики разработки

Защитное программирование
Обзоры кода
Проектирование
Тестирование
Экстремальное программирование

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

Защитное программирование – это методика, когда мы ведем разработку и само написание кода помогает нам не допускать ошибок. То есть, в этом случае мы что делаем? Мы проверяем данные.
Элементарный пример – у нас есть какая-то функция, которая принимает входные параметры определенного типа, определенных значений. Мы можем в функции сделать предположение (так называемый инвариант или утверждение) и проверить эти предположения. То есть, мы не пишем, как 1С привыкла: параметр и в комментариях пишем, что тип такой-то, значения такие-то, варианты и так далее… Мы можем прямо написать утверждение – вот этот параметр должен быть такого типа. Если это утверждение не выполняется, программа просто выдает исключение и останавливает свою работу, потому что это является ошибкой разработки.
Следующая методика – это «Обзоры кода». То есть, мы можем читать чужой код. То есть, один кто-то написал код, мы можем попросить соседнего разработчика, руководителя посмотреть и проанализировать ошибки, которые были допущены в этом коде. Это методика очень эффективна.
Я люблю читать чужой код, люблю свой код пересматривать. Таким образом находится достаточное число ошибок.
Следующая методика - проектирование. Чем лучше мы построим программу, чем лучше продумаем связи, чем лучше продумаем архитектуру, интерфейсы взаимосвязей, тем лучше наша система будет работать, тем удобнее нам ее будет исправлять.
Методика, которая известна лучше всех предыдущих – это тестирование. Фактически, каждый разработчик выполняет эту функцию, применяет методику тестирования. Но очень многие проверяют в уме. То есть этот код должен получить такие-то результаты… Мы проверяем какой-то один вариант, проверяем два варианта, проверяем три варианта… А на самом деле в сложных системах вариантов очень много и их нужно проверять достаточно большое количество. И когда вариантов очень много для проверки, фактически получается, что они не проверяются все. У меня есть пример, есть система, идет цикл разработки, система отдается на проверку пользователю. У пользователя стоит тестирование – проверить 40 разных пунктов – релиз выпускается, например, раз в два месяца (или в месяц). Пользователь должен перед выпуском каждого релиза проверить 40 пунктов – это тяжело и он никогда практически не будет этого делать. Он будет помнить, что он это проверял в прошлый раз – и сегодня он этого делать не будет, потому что тогда на это придется потратить весь день. Как правило, отдельный тестировщик на проекте есть очень редко, обычно человек должен выполнить функцию тестировщика и выполнить свою основную функцию. В итоге функции тестировщика, как правило, пропускаются и тестирование не выполняется в полном объеме.
Дальше я еще потом на тестировании остановлюсь…
Следующая – очень эффективная методика – это методика экстремального программирования. Это методика свежая, буквально начала-середины 90-х годов. На западе очень сильно распространена, очень много информации по ней. У нас применяется не так много. Иногда эту методику называют «гибкие методики разработки», иногда – экстремальное программирование.

Экстремальное программирование

У него есть несколько принципов:

Единая команда
Совместное владение кодом системы
Обзоры кода и парное программирование
Разработка через тестирование (TDD)
Функциональное тестирование
Рефакторинг
Простота
Короткие циклы
Непрерывная интеграция
Улучшение дизайна, постоянное планирование

Расскажем о них поподробнее:

Первый принцип – это единая команда. Единая команда – это означает, то команда работает вместе. Каждый член команды осведомлен о целях проекта, о задачах, которые необходимо выполнить, как идет проект, на какой стадии он находится.
Есть еще такое понятие в экстремальном программировании – я его даже не стал тут выделять, потому что это достаточно сложно для понимания – есть такое понятие – «метафора». То есть, у проекта, который находится в экстремальном программировании, должна быть единая метафора, единое простое представление, что делает система. Эта метафора может не относиться к какой-нибудь конкретной задаче, ее можно именно представить в уме – команда просто должна представлять себе, что это такое – небольшим набором слов (одна-две фразы). Но эта метафора должна быть.
Из единой команды есть следствие, что код, на котором пишется система – общий код не должен являться чьей-то собственностью. Код должен быть совместным. То есть – любой разработчик может исправить любое место кода. Это очень важный принцип и очень часто он нарушается. То есть – у нас пример – есть какой-то разработчик, который обладает большими знаниями, большими способностями, знает какую-то конкретную методику или знает предметную область, которую должен решить и он не пускает никого в свой код. Фактически для проекта это плохо.
Этот разработчик владеет полностью своим кодом и проект полностью в этом месте может заморозиться. Он зависит только от этого разработчика. Для проекта это очень вредно.
Совместное владение кодом влечет за собой возможность гибко менять проект, возможность единого владения всеми членами команды знаниями о коде. В результате мы не зависим от конкретных людей (человек заболел, ушел, уволился) – у нас система проекта остается в работе и вся команда дальше работает вместе.
Есть еще соответственно методика - парное программирование или обзоры кода. По парному программированию, это – фактически работают два пользователя, два разработчика. Один разработчик пишет непосредственно код, проектирует, второй сидит рядом и выдает ему комментарии, что ты здесь сделал неправильно, ты здесь сделал ошибку и т.д. Строго говоря: один пишет – один контролирует.
Это единственная методика, которую я не применял, то есть у меня к ней подозрения – не могу ее рекомендовать, потому что не проверял.
Обзоры кода, как я уже сказал – я применял – то есть, это очень полезная методика.
Дальше – следующая методика, которая используется в экстремальном программировании – это разработка через тестирование (TDD). Смысл этой методики я раскрою дальше, расскажу пока что очень кратко.
Сначала пишутся тесты. Потом пишется код под эти тесты. После того, как тесты проходят – код считается завершенным.
Цикл: тест – код – тестирование.
Код никогда не пишется до тестов.
Дальше – есть функциональное тестирование, иногда называется «Приемочные тесты». Это то тестирование, которое выполняет заказчик.
Обязательно, как я уже говорил – единая команда, заказчик всегда участвует в команде. Он принимает участие во всех этапах проекта. Готовит сам тесты. То есть – заказчик обязательно должен участвовать – это тоже одно из требований экстремального программирования.
Очень важный фактор экстремального программирования – это рефакторинг.
Рефакторинг – это изменение кода (важное условие – изменение работающего кода).
То есть, не добавление какого-либо функционала – только исправление работающего кода для того, чтобы увеличить его качество, упростить связи, интерфейсы и так далее.
Также очень важный параметр экстремального программирования – это простота. Проект стремится быть максимально простым по дизайну, по реализации. Не придумывается никаких лишних дополнений/допущений. Проект работает «на сегодня». Он не работает на будущее – через 10 лет, через 5 лет. Он, как правило, работает на сегодня. То есть – у нас есть требования, мы, в общем-то, продумываем эти требования, думаем о масштабировании, об увеличении, но стараемся писать, стараемся выполнять проект только для текущих задач.
Следующее понятие – это короткие циклы. То есть, итерации проекта несут очень маленький характер. Если один разработчик – 5-10 минут, написал тест, код, проверил – идем дальше.
В результате коротких циклов у нас есть уверенность в том, что система работает и все тесты проходит. Но это – опять же, все основано на тестах.
Есть еще такое понятие – непрерывная интеграция. Для 1С это, в общем-то, не так часто используется, но – тем, кто работает в коллективной разработке, с хранилищем, это должно быть известно, - то есть, изменения в основное хранилище должны вноситься очень часто.
Разработчик добавил какой-то функционал в свой небольшой участок, протестировал его и обязательно занес в основной код.
Не через месяц, не через неделю – а часто, раз в день (так называемые «ночные сборки»). То есть, в течение дня выполняется работа. Ночью происходит «ночная сборка». Это можно автоматическими средствами выполнять. Выполняются тесты – например, ночные тесты - полностью все тесты. Если система полностью прошла все тесты – значит, наутро мы признаем, что функционал у нас принимается – делаем новую сборку системы.
Еще одно важное требование экстремального программирования – это улучшение дизайна.
Всегда каждый разработчик думает о дизайне системы. Думает, как улучшить систему, как устранить дублирование, какие части кода не нужны в системе. Постоянно планирует. Заказчик в этом тоже непосредственно участвует, как я уже говорил.

Вернемся к тестированию. Будем говорить только о тестировании.

Виды тестирования

Модульное тестирование (юнит-тестирование)
Функциональное тестирование
Тестирование методом черного ящика и методом белого ящика
Нагрузочное тестирование
Тестирование разработчиком и специальными тестерами
Самый проблемный вид тестирования – тестирование пользовательского интерфейса

Теперь об этих видах тестирования подробнее:

Самое основное, про которое я буду в дальнейшем рассказывать – это юнит-тестирование или так называемое модульное тестирование. То есть, это тестирование частей системы, компонентов, модулей. Это самое простое, что может делать разработчик – любой причем разработчик 1С – как один человек, так и команда. Это самое простое – здесь нет никаких дополнительных проблем. Все зависит от разработчика и от той системы тестирования, которую он использует.
Дальше – есть такой термин – функциональное тестирование или приемочные тесты или – там несколько названий – это тесты всей системы в целом.
То есть – смотря что мы разрабатываем – если мы пишем какой-то отчет, это может быть формирование отчета – какие данные из него получаем. Если это проект в целом – то это проверка всего пользовательского интерфейса.
Есть тестирование методом белого и черного ящика.
Методом черного ящика – это соответственно, мы ничего не знаем о системе, как она функционирует. Мы знаем только то, что подается на вход системы и то, что подается на выход системы. И можем проверить только эти соотношения. Это, как правило – тестируют специальные тестировщики. То есть, вот например, функциональное тестирование очень часто тестируют именно методом черного ящика.
Есть метод белого ящика – то есть, мы опять же знаем, что у нас внутри, как организован проект, какие идут связи и можем более точно построить тесты, например, предположить, что на каких-то граничных условиях наши тесты могут падать.
Следующий вид тестирования – это нагрузочное тестирование или стрессовое тестирование.
Это проверка на какие-то граничные факторы системы, например, на работу с очень большим количеством пользователей, или работу с условием – мало памяти, мало места на жестком диске и т.д.
Также тестирование может выполняться разработчиком или специальными тестерами.
Но в своей работе, как правило, я видел, что тестирований специальными тестерами выполняется либо мало, потому что средств тестирования очень мало, либо они очень дорогие.
То есть, организацию тестирования специальными тестерами сделать довольно сложно. Тестирование разработчиком – это самое простое, потому что это может выполнить любой 1С-ник независимо от своего уровня.
Самый проблемный вид тестирования – это тестирование пользовательского интерфейса. То есть, здесь очень сложно организовать, потому что, например, в 1С8 построено все на собственной оконной системе, значит, сторонние какие-то программы не могут получить информацию о том, что происходит в 1С.
А в 1С до недавнего времени не было возможности обратиться и протестировать интерфейс.
Но – есть уже система тестирования интерфейса в 8.3 и есть система, которая называется «Тест-Комплит», которая позволяет протестировать пользовательский интерфейс, но ее цена – 2500 долларов. Эта система позволяет тестировать любые приложения - .NET приложения, Web-приложения, 1С-приложения (в 7.7 – я лично проверял), но очень дорогое, конечно, лицензирование.

Сейчас немного коснусь существующих систем тестирования

Существующие системы тестирования

Первое, с чем мы знакомы, когда говорим «Тестирование 1С» - это, конечно конфигурация «Сценарное тестирование» (входит в пакет 1С:КИП).
Мое мнение вкратце – не пригодно оно к реальному использованию.
Оно сделано больше для функционального тестирования и очень сильно зависит от изменений в программе.
Если в форме добавился какой-то реквизит, Сценарное тестирование может вылетать, если в форме удалился какой-то реквизит – Сценарное тестирование может вылетать.
Нет возможности исключить ошибки, прогнать все тесты за исключением ошибок. Если есть ошибка, тест остановится весь.
Кроме этого, неприятным моментом является то, что конфигурация «Сценарное тестирование» не продается отдельно от пакета конфигураций «Корпоративный инструментальный пакет». А цена этого пакета очень велика.
Хотя – лично мое мнение, что тестирование в 1С должно быть бесплатным.
Есть очень хорошая подсистема (автор - Сергей Старых) – называется Подсистема «Инструменты разработчика».
В этой подсистеме недавно появилось тестирование. Были введены начальные понятия тестирования – тестируются все формы и часть метаданных, то есть, тестируется открытие всех форм, которые есть в конфигурации, для документа тестируется проведение документа, запись документа, удаление документа и т.д.
Самое интересное – тестируются события и интерактивные изменения форм.
Например, тестируется ввод пользователем. Как будто пользователь вручную вносит данные. Это очень важно.
Не в одной из систем, о которых я расскажу далее, нет тестирования этих интерактивных изменений. Например, там можно протестировать поиск по форме (по списку). То есть, как будто пользователь набирает символы, и подсистема это отрабатывает. Очень полезный инструмент.
Еще есть некоторые публикации на сайте «Инфостарт».

3.1. Тестирование конфигураций на открытие форм – //infostart.ru/public/21489/

Одна из самых первых разработок, поэтому я о ней упомянул.
Она неудобная и непродуманная на самом деле.

3.2. Есть модуль юнит-тестирования – //infostart.ru/public/22168/ (2015 - Автор удалил свою разработку, ссылка недействительна)

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

3.3. FuncTest.v8 - infostart.ru/public/19631/ (2015 - Автор удалил свою разработку, ссылка недействительна)

достаточно интересная, но почему-то автор ее удалил

3.4. Очень интересная разработка Тестирование (//infostart.ru/public/82718 ) Содержит:

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

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

4.1. Есть система юнит-тестирования для 1С 7.7 – это в свое время я и другие мои товарищи использовали при разработке ВК 1С++ и FormEx (www.1cpp.ru )

Эта система реально позволяет использовать разработку через тестирование (TDD) для 7.7
В свое время, благодаря использованию этой системы юнит-тестирования разработка ВК 1С++ стала намного более стабильной, и мы смогли получить стабильные, непадающие версии ВК

4.2. Есть также система Functest для 7.7 (автор Федор Езеев и я там тоже немножко дорабатывал в свое время) (http://1c.alterplast.ru/functest/ )

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

4.3. Собственная система Functest для 8.1/8.2 (//infostart.ru/public/15492 )

Я ее в 8.2 до сих пор успешно использую.
Недостатки: немного устарела, нет управляемых форм

4.4. Предпоследняя система – это система юнит-тестирования SnowTest для 8.1/8.2 (www.1cpp.ru/forum/YaBB.pl?num=1267016427/0 ). Автор тоже Федор Езеев.

Ее как раз тоже можно использовать при разработке через тестирование (TDD) в 8.2

4.5. В новой платформе 8.3 наконец-то появилось более продвинутое тестирование, чем сценарное тестирование. Это система тестирования интерфейса (http://v8.1c.ru/overview/Term_000000816.htm )

Шаги в нужном направлении
Только Управляемое приложение

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

То есть, толстый клиент или тонкий клиент менеджер тестирования взаимодействует (общается) с клиентом тестирования (толстым, тонким или Web-клиентом).
То есть – пишется тест на языке 1С. И заданные действия выполняются в клиенте тестирования.

Пример вызова приложения-теста

На данном скриншоте красная стрелка как раз показывает – есть вариант вызова записи действий пользователя, то есть в 8.3 можно использовать следующую схему работы:

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

(я фактически ее product-owner и один из авторов) -

https://github.com/xDrivenDevelopment/xUnitFor1C/wiki (2012-2015 гг.)

В ней огромное количество возможностей, поддержка от 8.2.13 - до 8.3.5.ХХХ, запуск из командной строки, работа с build-серверами, есть хорошая документация, есть много примеров и тестов, есть видеотренинги и видео-примеры.

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

Система активно развивается как после первой конференции Инфостарт-2012

Защитное программирование

Защитное программирование – очень важный этап применения методики тестирования

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

Использование инвариантов/утверждений

Утверждения (assertion) – это код (метод или макрос), с помощью которого проверяется правильность заданного условия. В случае, если условие не выполняется, просто выбрасывается исключение – программа прекращает свою работу
Утверждения можно использовать только для проверки инвариантов, то есть постоянных условий – событий, которые никогда не должны произойти(считаются недействительными)
- Пример вызова:
  C++ assert (value !=0);
  1C артТесты. ПроверитьЗаполненность (парамКонтрагент, «Метод1::Не задан контрагент»);
- В 1С в связи с тем, что нельзя получить контекст выполнения, приходится делать более сложный код – поэтому здесь утверждение принимает два параметра – первый параметр - это данные, которые нужно проверить, а второй параметр – это сообщение для анализа.
- Главная задача утверждений – выявить противоречивые допущения, некорректные значения и условия в ходе разработки программы
- Утверждение должно останавливать программу. Это – самое главное. Никаких проверок, никаких обработчиков – только останавливать – вызываем метод «ВызватьИсключение».

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

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

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

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

Теперь – самое интересное: Тестирование разработчиком и разработка через тестирование.

Тестирование разработчиком

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

Затруднение у разработчиков (Цель тестирования отлична от других этапов разработки, Тестирование требует поиска ошибок в своем коде)
Тестирование разработчиком вызывает затруднения, потому что цель тестирования отлична от цели разработки. То есть от разработки мы хотим получить правильный код, который правильно работает, получает верные результаты, содержит минимум ошибок и т.д. А в тестировании мы должны найти ошибки, наоборот. Иногда бывает это трудно. Разработчику бывает лень искать ошибки. Разработчик не понимает, что ошибки нужно искать и т.д.
Тестирование никогда не доказывает отсутствия ошибок.
Но наличие тестов – это лучше, чем отсутствие тестов.

Что еще можно сказать об основных требованиях к тестированию:

Два главных требования тестирования:

Тестирование должно быть автоматизированным. А еще лучше – автоматическим 100%. Если тестирование не будет автоматизированным, его никто никогда выполнять не будет.
Тестирование должно быть быстрым.
Если тесты будут выполняться медленно, их опять же никто не будет делать. Это все из опыта.

Разработка через тестирование (TDD)

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

Результаты использования TDD

Быстрое нахождение ошибок и исправление ошибок
В результате того, что мы используем тесты до разработки, мы быстро находим ошибки. Потому что пишется тест – потом небольшой кусок кода - проверяется.
Если тест упал – значит, вот у нас ошибка – в этом коде из 15-20 строк, и мы легко ее находим – на надо искать несколько часов в модуле из 20 экранов.
Отладка становится очень простой либо вообще не используется
Я отладку использую очень редко. Потому что у меня все в тестах, как правило. В крайнем случае я пишу отладочные сообщения. Это более эффективно, чем ходить по коду, искать ошибки и т.д.
Уверенность в качестве ПО
У того, кто применяет методику TDD, появляется уверенность в качестве ПО. Он видит, что система работает. Видит, как у него проходят тесты. У него появляется психологическая уверенность.
Простота доработки/рефакторинга
Соответственно, поскольку у нас есть тесты – нам легко дорабатывать свою систему. Мы легко можем вносить изменения согласно требованиям заказчика и т.д.
Выбор проектных решений, например, интерфейсов взаимодействий и дизайна программы.
Тестирование позволяет нам также заранее принимать проектные решения, т.е. интерфейсы, связи различных модулей, дизайн программ. Например, я вот работаю так – у меня есть задача сделать какую-то выгрузку. Я сначала делаю тесты, продумываю эту выгрузку. Когда мы пишем тесты, мы фактически продумываем дизайн программы. То есть я не рисую ничего в формах – все делается в модуле. Продумываю и только потом, когда моя программа проходит все тесты, которые я сам для себя определил, только после этого я рисую форму, в которой использую только нужные мне данные, которые нашел в результате тестов. То есть, в тестах у меня задан дизайн программы – это очень важно и это на самом деле удобно.
Разработка через тесты позволяет нам создать слабосвязанные модули.
Когда мы пишем тест, если модули очень сильно связаны между собой, очень сложно написать хороший тест. Приходится городить неизвестно что. В результате тест не проходит, потому что у нас есть много связей. Приходится облегчать эти связи, т.е. переписывать код, переписывать тест. Зато в результате мы получаем слабосвязанную программу. И это правильно.
Еще один важный фактор, про который забывают – это создание документации.
Очень часто у нас документация не связана с программой, т.е. происходит изменение в программе, документация, как правило, отстает от программы. А тесты всегда соответствуют программе. То есть – тесты выступают как всегда актуальная и доступная документация. То есть, если я возвращаюсь через полгода к проекту, который я выполнил на тестах, я первым делом смотрю в тесты и вижу, как все сделано. Если мне нужно доработать, я уже дорабатываю в соответствии с тестами.

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

Принципы (правила) разработки через тестирование

Основные принципы:
- Не пишите код, пока не будет написан автономный тест, который не проходит
- Не пишите тест в объеме большем, чем нужно для отказа
- Не пишите код больше, чем необходимо для прохождения теста
- Устраняйте дублирование
- Используйте утверждения для проверки теста
- Используйте автоматизированную среду запуска тестов
- Запускайте тесты часто
- В случае успеха нужна простая «зеленая» полоса. Иногда начинающие пишут много различных сообщений – это путает.
- Подробные сообщения и «красная» полоса нужны только при отказе теста (для неверных тестов)

Все просто:

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

Здесь у меня представлен цикл тестирования. Он очень простой:

TDD - цикл тестирования/кодирования

Пишем тест. Компилируем. В 1С под компиляцией понимается успешное прохождение проверки синтаксиса.
Запускаем тест. Убеждаемся, что он не проходит в режиме выполнения.
Пишем код в том объеме, который нужен для успешного срабатывания теста в режиме выполнения.
Запускаем тест и убеждаемся, что он корректно отработал
Обязательно выполняем рефакторинг для «чистоты» кода, устраняем дублирования. Исправляем свой тест, чтобы он стал проще, легче. Исправляем свой код.
Повторяем последовательность сначала
Главное - использовать короткие циклы в разработке, чтобы поиск ошибок был наиболее упрощенным

TDD – принципы написания тестов

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

Выводы:

Для построения качественного ПО нужно использовать различные методики, а также комбинации различных методик
Используйте утверждения для повышения качества кода
Использование тестирования снижает затраты на разработку и сопровождение
Тестирование не гарантирует нахождение всех ошибок
TDD и тестирование повышают надежность ПО и качество системы
Работа разработчика становится более эффективной
Работа в режиме TDD приносит больше положительных эмоций
Вход в TDD не так сложен, как кажется тем, кто не знаком с TDD

Литература

С.Макконнел. Совершенный код
К.Бек. Экстремальное программирование
К.Бек. Экстремальное программирование: разработка через тестирование
М.Фаулер. Рефакторинг - улучшение существующего кода
Р.С.Мартин, М.Мартин. Принципы, паттерны и методики гибкой разработки на языке C#
К.Ауэр, Р.Миллер. Экстремальное программирование. Постановка процесса с первых шагов и до победного конца.
Р.С.Мартин. Чистый код

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

Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.

+243 –

См. также

Автотесты для типовых конфигураций 1С:ЗУП КОРП 3 и ЗУП 3 (vanessa automation)

DevOps и автоматизация разработки Тестирование QA Программист Пользователь Платформа 1С v8.3 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Зарплата и Управление Персоналом 3 и версии КОРП: 3.1.30.57.

2160 руб.

05.08.2024 1277 12 1

Автотесты для типовых конфигураций ERP 2 и КА 2 (для vanessa automation)

Тестирование QA DevOps и автоматизация разработки Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарии возможно использовать как для vanessa-automation, так и для СППР. Поддерживаемые версии конфигураций ERP2 и КА2: 2.5.17.113.

2400 руб.

04.07.2022 8368 38 1

Автотесты для типовых БП КОРП 3.0 и БП 3.0 (vanessa automation)

Тестирование QA DevOps и автоматизация разработки Программист Пользователь Платформа 1С v8.3 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Налоговый учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Бухгалтерия предприятие 3.0 и версии КОРП: 3.0.156.30.

1800 руб.

20.01.2022 7783 19 0

В облако на работу: Вишенка на торте. Быстродействие оборудования, нагрузочное тестирование, балансировка нагрузки в кластере серверов 1С на базе РЕД ОС 8

Облачные сервисы, хостинг Linux Тестирование QA Сервера Системный администратор Программист Платформа 1С v8.3 Бесплатно (free)

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

31.10.2024 1308 capitan 0

Логирование в приложениях

Журнал регистрации Тестирование QA Программист Бесплатно (free)

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

21.10.2024 2780 leemuar 8

Старт в юнит-тестах

Тестирование QA Пользователь Платформа 1С v8.3 Розничная и сетевая торговля (FMCG) Россия Бесплатно (free)

Юнит-тесты в 1С – это круто!

04.10.2024 2717 Sakharyuk_Ilya 8

Бей мутантов – спасай код

Тестирование QA Системный администратор Программист Платформа 1С v8.3 Бесплатно (free)

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

30.08.2024 1292 Scorpion4eg 6

Много тестовых баз 1С и много разработчиков. Как работать, чтобы не запутаться

Тестирование QA Программист Платформа 1С v8.3 Бесплатно (free)

Иногда возникают ситуации, когда надо развернуть тестовую базу клиента / свою на серверах Windows или Linux. Тестовые базы могут понадобиться в разных ситуациях: у клиента ошибка, на нашей базе она не воспроизводится, реализуем новый функционал и хотелось бы протестировать на Linux и т.д. А теперь представим, что это все на потоке. Что тестовых баз 1С не одна, а 20-30. И получаем проблему, что непонятно, занята она сейчас кем-то или нет. Предлагаю вариант решения этой проблемы.

28.06.2024 1511 Diversus 12

Отзывы

50. artbear 1563 07.10.16 20:40 Сейчас в теме

(49) Можешь писать здесь.
Можешь создавать issue на проекте, как ты сегодня и сделал.
Можешь писать в официальном чате https://gitter.im/xDrivenDevelopment/xUnitFor1C

2 последних варианта предпочтительнее.

Остальные комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. zorka-gold 09.02.15 14:16 Сейчас в теме

Много битых (не рабочих) ссылок !

2. artbear 1563 09.02.15 16:13 Сейчас в теме

(1) Ага, есть такое, все-таки выступление двухлетней давности.
Ссылки поправлю в ближайшее время.

3. artbear 1563 09.02.15 16:27 Сейчас в теме

(1) Исправил ссылки
Также добавил абзац
Рекомендуемая система для тестирования в 1С (я фактически ее product-owner и один из авторов) - https://github.com/xDrivenDevelopment/xUnitFor1C/wiki (2012-2015 гг.)
В ней огромное количество возможностей, поддержка от 8.2.13 - до 8.3.5.ХХХ, запуск из командной строки, работа с build-серверами, есть хорошая документация, есть много примеров и тестов, есть видеотренинги и видео-примеры.

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

Система активно развивается как раз после той самой, первой конференции Инфостарт-2012

4. awk 744 09.02.15 19:04 Сейчас в теме

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

Специально обученные отделы тестирования, крайне не любят данный метод. Говорят, что он только сбивает.

8. artbear 1563 10.02.15 13:32 Сейчас в теме

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

19. awk 744 16.02.15 23:06 Сейчас в теме

(8) тестировщику и не надо знать. Программисту - наверное надо.

21. artbear 1563 16.02.15 23:40 Сейчас в теме

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

5. baloo 09.02.15 19:30 Сейчас в теме

В профессии уже 10 лет. 7.7-8.0-8.1-8.2-УТ-БП-УПП-итд-итп. Где-то полгода назад начал на досуге изучать веб-разработку, RoR, через него и вкусил TDD. Сильно заинтересовало, стал изучать литературу, пробовать применять к 1С. Сказать, что это изменило мой стиль разработки - не сказать ничего, это буквально перевернуло устоявшийся и "закостеневший" за годы процесс. Натыкался до НГ на упомянутый проект на гитхабе, разбирался, хотел присоединиться к разработке, но потом НГ, отчетность, дела, обучение, как обычно, короче, толком в курс не вошёл. В статье упомянуто про "видеотренинги и видео-примеры", где их можно посмотреть, киньте ссылкой плз.

6. artbear 1563 09.02.15 23:45 Сейчас в теме

(5) Например, http://infostart.ru/public/328695/

9. slazzy 42 10.02.15 15:12 Сейчас в теме

(6), Можно позадавать Вам пару вопросов по ходу обдумывания материала? :)

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

В чем критическая для разработки разница между accert и простой проверкой, которая в общем-то почти всегда используется в 1С. Если она не используется, то всё печально :)

Так же стоит упомянуть, что в БСП на текущий момент введен аналог функции accert, а именно
ОбщегоНазначенияКлиентСервер.Проверить И
ОбщегоНазначенияКлиентСервер.ПроверитьПараметр
Которые в самой БСП как раз как типичный accert из С++ и используются.

Я вообще с С++ не знаком почти, но там же где я узнал про accert вумный парень говорил, что вообще-то в С++ accert используется только на этапе разработки и в релизных версиях почти все ассерты удаляются из кода. В 1С это ещё более критично, тк если использовать типовой способ из БСП и проверять все параметры в функции, то мне кажется это сильно замедлит работу функции. Но в статье про это ни слова :) или это не так?

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

10. artbear 1563 10.02.15 18:16 Сейчас в теме

(9) Механизм утверждений/assert-ов (не accert) предназначен именно для подтверждения контракта функции/процедуры и отличается от стандартных проверок параметров тем, что не возвращает некое значение в вызывающую функцию, а сразу выбрасывает исключение, прерывая выполнение кода!!
Это важный момент.
Фактически утверждение говорит о том, что заданы жесткое условие/состояние (инвариант), которому должны удовлетворять функция/процедура.
Здесь неважно, какое условие/контракт проверяется.
Например, можно проверять тип входного параметра, его значения и т.п.

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

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

38. zqzq 25 25.03.15 16:30 Сейчас в теме

(6) посмотрел видео про змейку и прочее, очень познавательно, но... как-то от обычных 1С-ных задач далеко. В результате так и не очень понятно, как применять это TDD(Бека тоже почитал, но он работу с БД не любит и примеры с ООП не всегда гладко на 1С ложатся). В идеале нужно что-нибудь вроде примера решения задачи с 1С-ного билета по специалисту через тестирование.

40. artbear 1563 25.03.15 16:58 Сейчас в теме

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

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

ОФФ. что-то Инфостарт совсем перестал информировать о новых сообщениях в моей же ветке :(

42. zqzq 25 26.03.15 09:02 Сейчас в теме

(40) на сайте 1с есть пример билета и каркасная конфигурация:
http://www.1c.ru/rus/partners/training/questions.htm
Можно взять первую задачу - оперативный учет. На экзамене на неё отводится примерно 60-90 минут. По-моему, она сильно ближе к реальным 1с-овским задачам, чем змейка, а вот как подступиться с помощью 1с-ТДД непонятно (действительно, может не 1 день занять, особенно с непривычки).

7. lustin 10.02.15 06:51 Сейчас в теме

(5) baloo, вот за RoR отдельное спасибо - мы в процессе работы очень много вдохновения именно оттуда черпаем. И да - "мозг меняется".

11. sergei2k 10.02.15 19:08 Сейчас в теме

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

12. artbear 1563 10.02.15 19:35 Сейчас в теме

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

Когда я осенью 2012 года был на партнерской конференции в Москве, в Космосе, специально подходил к разработчикам сценарного тестирования.
Они показывали как раз сценарное тестирования для упр.приложений, внутреннюю альфа-версию
Они мне сообщили, что на тот момент им неизвестно о тестировании продуктов упр.приложения (УТ 11, УНФ и др.) средствами автотестирования 8.3 :(

13. so-quest 140 11.02.15 10:59 Сейчас в теме

http://infostart.ru/public/22168/ ничего интересного из себя не представляет.

https://github.com/wwall/xUnitFor1C - тут добавлена поддержка проверки равенства структур. Может кому потребуется

14. artbear 1563 11.02.15 11:58 Сейчас в теме

(13) ты бы это как-нибудь документировал для понимания сторонними разработчиками.
А я бы тогда подумал о включении в основной xUnitFor1C :)

15. AlexSunS 15.02.15 17:34 Сейчас в теме

Как много веяний "новых" на ИС.

16. artbear 1563 16.02.15 01:02 Сейчас в теме

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

17. minimajack 80 16.02.15 20:13 Сейчас в теме

(16) лишнее

юТест.ПроверитьБольше(ТестовыеДанные.Количество(), 0, "Ожидали, что загрузка макета загрузит данные больше 0");

вы же не юнит-тестирвание проверяете

18. pumbaE 16.02.15 20:31 Сейчас в теме

(17) 1с и чистый юнит-тест не совсем совместимы.

22. minimajack 80 17.02.15 08:02 Сейчас в теме

(18) pumbaE, (20)
имхо:
я к тому что "ПроверитьБольше" - это "от черта".
либо равенство количеству строк (количество = 5), либо равенство на булево ( количество > 0 )...
само по себе "больше" не помогает в тестировании, а наоборот помогает скрыть ошибки, т.к. проще написать больше 0 и забить

23. artbear 1563 17.02.15 19:32 Сейчас в теме

(22) ты прав, а мы внимания не обратили.
ПроверитьБольше здесь от "лукавого"
В Вики поправил, вообще удалив эту ненужную строку.
Спасибо!

24. pumbaE 18.02.15 09:12 Сейчас в теме

(22) minimajack, не соглашусь. Не в данном случаи, а в общем. ПроверитьБольше дает большее представление об ошибке чем "проверить(Количичество()>0) ", сразу видно что передано, параметр 1=0, параметр2(проверки) = 0 и уже в пояснении достаточно написать просто "ТЧ Товары.Количество()". В случаи же проверки истины, нам в пояснении надо писать "ТЧ Товары.Количество() = 0" и т.д., повторять тот же код, который мы пытались проверить.

25. artbear 1563 18.02.15 10:14 Сейчас в теме

(24) Женя, я лично считал, что в (22) говорится о ПроверитьНеРавенство(0, Таб.Количество()) или ПроверитьРавенство(5, Таб.Количество())
ПроверитьИстина(Таб.Количество() > 0) или ПроверитьИстина(Таб.Количество() = 5) явно плохо.

26. minimajack 80 18.02.15 12:24 Сейчас в теме

(24) pumbaE, по идее в тестах мы заранее знаем точное значение ожидаемого результата, и именно это значение надо использовать как написано в 25, если это невозможно использовать ( а это очень и очень маловероятно...по крайней мере в 1С8 без ВК и внешних сервисов) - использовать ПроверитьИстина(Таб.Количество() > 5) с описанием ошибки вручную - вплоть до ссылки на описание почему именно это значение.
Пример:
один и тот же набор данных используется при тестировании двух отчетов. Изменяют первый отчет(вывод дополнительных данных, новый тип операции и т.п.) -> меняют исходные данные (тестовый файл) -> меняют тест по первому отчету -> все ок; при этом второй отчет на ошибке ПроверитьБольше 0 все также будет проходить, но не факт что результат отчета будет идентичный. Если бы стояло ПроверитьРавенство(5, Таб.Количество()) - ошибка сразу стала бы известна - именно на этапе загрузки данных, а не по факту. То есть найти ошибку будет проще. И именно поэтому, я написал "помогает скрыть ошибки".
ПроверитьНеРавенство(0, Таб.Количество()) - аналогично скроет ошибку.
Использовать скрытое сравнение как ПроверитьИстина(Таб.Количество() = 5) - тоже плохо, как минимум тем что используется не по назначению и неудобно для рефакторинга.
ИМХО оптимальный ПроверитьРавенство(5, Таб.Количество()) - дает наиболее точный результат
В общем все это мое личное мнение. Я никого не принуждаю писать код именно так, просто исходя из своего опыта даю рекомендации.

27. artbear 1563 18.02.15 15:24 Сейчас в теме

(26) Да, согласен, что ПроверитьРавенство(5, Таб.Количество()) наиболее оптимально.
пара уточнений:

лучше писать ПроверитьРавенство(5, Таб.Количество(), "Таб.Количество()") или ПроверитьРавенство(5, Таб.Количество(), "количество созданных объектов")
ИМХО лучше вообще исключить эту проверку, как я сделал в Вики, т.к. в данном случае утверждение проверяет создание тест.данных, т.е. функционал, который вторичен для данной задачи. для этой задачи важно проверить именно соответствие результата отчета эталону, а не создание данных.

20. artbear 1563 16.02.15 23:38 Сейчас в теме

(17) Человек, который писал этот тест, еще не очень доверял методу юТест.СоздатьДанныеПоТабличномуДокументу :)
Поэтому и вставил подобную проверку для гарантии правильности теста.
А этот метод, как и многие в xUnitFor1C, либо работает и возвращает данные при правильном макете, либо падает с исключением, если макет неверен.

Как уже отмечено в (18), в 1С очень зыбкая граница между юнит-тестами и приемочными тестами.
Я лично давно уже не говорю "юнит-тесты" в 1С, а упоминаю именно тесты.

28. eugeniezheludkov 45 06.03.15 07:06 Сейчас в теме

Воу, хорошая статья , видимо ранее плохо искал раз не натыкался на неё. довольно хорошо и понятно разжевано именно как это реализовать на 1С. на хЮнит1С стал по другому смотреть! с удивлением для себя обнаружил там вики :). еще заинтересовала подсистема (автор - Сергей Старых) – называется Подсистема «Инструменты разработчика».
Тему в закладки, буду пытаться поднять её у себя (сейчас тестированием реальные люди занимаются).. если получится то отпишусь как и что вышло. ранее не находил дельной инфы и считал проект "костылем", приношу извинения.
яб еще добавил "статический анализ кода" на каком - нибудь этапе после код-ревью , т.е когда анализируется структура кода на возможные ошибки и даже неоптимальные участки кода (по шаблонам) во всяком случае для себя я простенький написал: ни одна типовая конфа не проходит 2 шаблона: "неиспользуемые(забытые переменные)","Запросы в циклах" на УПП к примеру это более 7000 таких неоптимальных участка. (выкладывал тут)

29. pumbaE 06.03.15 10:57 Сейчас в теме

(28) eugeniezheludkov, автоматизированя проверка конфигураций. Там есть попытка статистического анализа кода, но у меня терпения не хватает каждый раз ее проходить, видно в 1с та-же проблема.
p.s.: когда 90% кода типового, то к сожалению не всегда есть желание посмотреть на чужие ошибки, которые вряд-ли будешь исправлять или будут исправляться.

31. eugeniezheludkov 45 07.03.15 06:36 Сейчас в теме

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

32. artbear 1563 07.03.15 11:28 Сейчас в теме

(31) Поделись кодом подобной проверки, очень интересно.

33. artbear 1563 07.03.15 11:32 Сейчас в теме

(32) Ага, увидел. Посмотрю, как сделано.

35. eugeniezheludkov 45 10.03.15 01:32 Сейчас в теме

(33) если что , тут последние коммиты , и сильно не пинайте за мои антипаттерны :( писал на коленке перед НГ

34. artbear 1563 07.03.15 11:33 Сейчас в теме

(31) А в чем проблема с реализацией автовыгрузки конфы на тексты? у нас давно реализовано - проект v83unpack

30. artbear 1563 06.03.15 14:17 Сейчас в теме

(28) (29) Да, пока только АПК остается.
Мы работаем над верификацией программ разными способами - синтакс-проверки, кросс-тестирование, автотесты, покрытие кода, код-ревью, АПК.
Минусы АПК (помимо скорости), о которых я говорил на общей стойке БСП/АПК на недавнем партнерском семинаре 1С - вся автоматизация внутри АПК, нет внешнего управления и возможности получения результатов проверки извне.
Мы пользуемся билд-серверами, они отлично себя показывают, и у меня в планах заставить АПК выполнять автопроверки именно через билд-серверы.

36. baloo 23.03.15 13:24 Сейчас в теме

По поводу проверки "Запросы в циклах" - у вас анализируется вызов в цикле процедур/функций, внутри которых совершается запрос? Кроме того, было бы здорово анализировать не только наличие явного исполнения запроса через запрос на встроенном языке запросов, но и обращение к реквизитам переменных ссылочного типа, что, по сути, влечет за собой неявное выполнение запроса к БД.
ПС обработку не видел, нисколько не критика - чисто размышления по улучшению :)

37. eugeniezheludkov 45 24.03.15 04:05 Сейчас в теме

(36) baloo, естественно анализируется вызов процедур и функций и неявные запросы (типа .НайтиПоКоду()) и отсекаются закомментированные вызовы, и детектируется вызов запросов в рекурсивных функциях https://github.com/znsoft/external1CProgs/blob/master/src/СтатическийАнализКода1с/Form/Форма/module тут можете глянуть исходный код модуля,
todo(если появится время):
-анализ вызываемых функций в другом модуле (к примеру вызов через точку от другого объекта) сейчас такая функция не проверяется :( можно реализовать если просто строить таблицу вызовов функций первым проходом и анализ вызовов вторым проходом
-анализировать обращение к реквизитам переменных ссылочного типа (чет я про них и забыл то сам сколько раз по молодости обжигался :) спасибо за подсказку)
-убрать проверку неиспользуемых переменных т.к такая проверка есть в конфигураторе :)

сейчас времени не очень много (много ТЗ в очереди), все мечтаю рефакторить обработку и вообще переделать на шарп (мой фаворит) или на java для будущих версий 1С :)

39. artbear 1563 25.03.15 16:45 Сейчас в теме

--
>http://forum.infostart.ru/forum24/topic123336/message1323894/#message1323894 >
> 22. magnetto72 24.03.2015 08:06
Я не могу понять как создать/зафиксировать эталон движений, где он должен сохраниться.
При тестировании отчета формирую его, создаю макет "Эталон", копирую в него табличный документ, получаю эталон с правильным результатами.
В "1С:Сценарное тестирование" для этого есть специальное действие "Сравнить движение документа с эталоном", которое снимает "слепок" с эталонной базы, сохраняет все значения в сценарий и затем при прогоне сверяет с тем, что получилось.

А как зафиксировать эталон для движений в xUnitFor1C?
---
Ответ: если мы говорим про отчет, то можно получить эталон прямо по отчету. Пример такого теста: Проверить отчет на соответствие эталону (исходный код модуля обработки) - с сайта xUnitFor1C

41. artbear 1563 25.03.15 19:42 Сейчас в теме

В дополнение к (39) см. (16)
Продублирую:
В Вики xUnitFor1C я документировал пример готового теста проверки отчета на СКД (со скриншотами и готовым кодом).
В тесте сначала создаются тестовые данные в базе, затем выполняется отчет на СКД, получается сводная таблица.
Эта таблица сверяется с эталоном.

43. kraynev-navi 681 20.11.15 15:44 Сейчас в теме

Подниму тему.
А можно как-то автоматизировать ввод названий тестов? Или может уже реализовано, не нашел?
Ну типа так:

Перем юТест;

Функция ПолучитьСписокТестов(ЮнитТестирование) Экспорт
	
	юТест = ЮнитТестирование;
        ВсеТесты = юТест.ПолучитьВсеТестыИзМодуляНачинающиесяНа("Тест_"); // ГЛАВНОЕ!
        // в результате в массиве будут два элемента "Тест_ДваПлюсДва()", "Тест_ДваПлюсТри()"
	Возврат ВсеТесты;
	
КонецФункции

Процедура ПередЗапускомТеста() Экспорт
	
КонецПроцедуры

Процедура ПослеЗапускаТеста() Экспорт
	
КонецПроцедуры

Процедура Тест_ДваПлюсДва() Экспорт
	
	юТест.Проверить(2 + 2 = 4, "Значение не верно");
	
КонецПроцедуры
Процедура Тест_ДваПлюсТри() Экспорт
	
	юТест.Проверить(2 +3 = 4, "Значение не верно");
	
КонецПроцедуры

Показать

44. artbear 1563 20.11.15 17:12 Сейчас в теме

(43) kraynev-navi, хороший вопрос, я давно им озадачен и борюсь с этой проблемой!

в "чистом" 1С невозможно получить список методов из объекта/модуля :( рефлексии нет!
в свое время я в 1С++ для 1С 7.7 я смог решить эту задачу и в нашей конфигурации тестировании для 1С 7.7 была такая возможность.

Для 1С с примесями :) в толстом клиенте обычных форм 8.2 для решения этой задачи я использовал написанный нами Информатор
можешь посмотреть метод юТест.ПолучитьПростыеТесты... (точное название не помню) из модуля обработки xddTestRunner

Соответственно для 8.3 или 8.2 УФ нельзя использовать подобный подход и остается юзать один из нескольких вариантов:

явно возвращать список тестов из теста через ПолучитьСписокТестов - штатный путь xUnitFor1C
если у вас установлен Снегопат, можно использовать написанный мной скрипт "Добавить описания тестовых случае xUnitFor1C" xUnitAddTestsDesc.js)
супер-хакерский путь - пишем обработку (или скрипт на 1скрипт), которая разбирает файл обработки, получает текст модуля, разбирает его, и добавляет код по возврату списка методов Тест_ХХХ в метод ПолучитьСписокТестов() :)

По последнему пункту - я сейчас постепенно пишу конвертер тестов из формата 3.Х в 4.Х, решение этого пункта будет в конвертере.
Ура, значит, я хакер :)

45. kraynev-navi 681 23.11.15 14:00 Сейчас в теме

(44)Собственно вопрос возник как раз после того, как сам хотел сделать быстренько и не обнаружил функционала у 1С )))
Обход понятен. Подожду вашу обработку ))

Следующий вопрос касательно обработки тесты_ОткрытиеФормКонфигурации.epf
В конфигурации был словлен следующий критичный случай. При тесте формы элемента журнал регистрации выглядит так. В первой транзакции (177013):

	Тесты "Открытие форм конфигурации"			Операция: Справочник.Организации.Форма.ФормаОрганизации
23.11.2015 9:25:16 (177013)	Данные. Изменение	Константа. Не использовать несколько организаций		
23.11.2015 9:25:16 (177013)	Данные. Изменение	Константа. Использовать несколько организаций		
23.11.2015 9:25:16 (177013)	Данные. Добавление	Справочник. Организации	<Объект не найден> (60:80e20050569e529911e591aaf11bdd91)

И далее идет удаление в ДРУГОЙ транзакции (505009)!

	Тесты "Открытие форм конфигурации"			Операция: Справочник.Организации.Форма.ФормаОрганизации
....	
23.11.2015 9:25:17 (505009)	Данные. Удаление	Справочник. Организации	<Объект не найден> (60:80e20050569e529911e591aaf11bdd91)

Все транзакции зафиксированы. Т.е. в первой транзакции константа поменяла свое значение и зафиксировалась. Вторая транзакция константу не привела к предыдущему значению.
Попутно вопрос, а почему они фиксируются? Почему не откатиться?

46. artbear 1563 27.11.15 11:12 Сейчас в теме

(45) Тест открытия формы запускает свою транзакцию.
Насколько я понимаю, константа фиксируется в какой-то внутренней транзакции, которая возникает при проверке формы "Справочник.Организации.Форма.ФормаОрганизации"
В итоге получается вложенная транзакция, результаты которой откатываются при завершении тестов.

47. nicxxx 255 07.10.16 16:19 Сейчас в теме

ветка жива еще? на гитхабе созданный тикет удалился через минуту, поэтому спрошу здесь: в тонком клиенте 8.2 можно как-нибудь запустить обработку xddTestRunner? версия 4.1.0.0 выдает ошибку "Тип не определен (ОписаниеОповещения)", потому что в этой версии платформы (8.2.19.83) еще нет такого объекта языка.
в обычном приложении обработка открывается.

48. pumbaE 07.10.16 16:48 Сейчас в теме

(47) nicxxx, почитайте https://github.com/xDrivenDevelopment/xUnitFor1C/releases там есть такой текст

4.0.0.7 последний релиз для 8.2

49. nicxxx 255 07.10.16 18:05 Сейчас в теме

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

50. artbear 1563 07.10.16 20:40 Сейчас в теме

51. nastrou1c 22 13.01.17 15:12 Сейчас в теме

Здравствуйте, Артур.
Спасибо за Ваш труд. Отличная статья и отличный инструмент.
Есть вопрос по вашему фреймворку xUnitFor1C:
Есть ли примеры использования штатного механизма автоматизации тестирования (http://v8.1c.ru/overview/Term_000000816.htm?printversion=1) в связке с xUnitFor1C?
Если есть - хотел бы попросить пример модуля тестирования.
Пример на github-е с открытием всех форм в решении видел и уже использую. Однако его не достаточно. Желательно автоматизировать именно сценарное тестирование заполнения форм, которое позволяет выполнять штатный механизм и использовать встроенные в фреймворк возможности по обработке и сохранению результата.

52. artbear 1563 13.01.17 15:58 Сейчас в теме

(51) Примеры, конечно, есть.
Например, тест Tests/Gui83/юнитТест_UI_83.epf
Вот ссылка на модуль формы теста, где видны все подробности кода теста

53. nastrou1c 22 15.01.17 12:26 Сейчас в теме

(52) Отлично, спасибо большое за наводку!

54. Artal 06.11.18 17:37 Сейчас в теме

Здравствуйте! Это просто великолепно, когда есть такие люди, как автор данного топика. Артур, спасибо вам за проделанную работу. Мне пока очень трудно оценить объем проделанной работы - но она бесспорно огромна.

Я так же познал дзен tdd, когда программировал на ruby. Это было прозрением. Временем быстрой и качественной разработки.

Теперь же я нахожусь в поиске фреймворка для применения методики tdd для внешних обработок, которые мне необходимо писать для конфигурации УТП 1.2 (конфигурация работает в режиме совместимости с версией платформы 8.2.13).

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

Очень интересно узнать от сообщества 1с программистов, которые по сей день программируют для платформы 8.2, какие именно инструменты (возможно в связке) они используют?

55. пользователь 07.06.22 17:42

Сообщение было скрыто модератором.

...

Оставьте свое сообщение

E-mail:

Автор:

Артур Аюханов (artbear)

Рейтинг: 1563

Для получения уведомлений о новых публикациях автора подключите телеграм бот: Инфостарт бот

Публикация:

№ 326820

Создание 09.02.15 13:17

Обновление 09.02.15 13:17

Статистика:

Просмотры 99121

Загрузки 0

Рейтинг 243

Комментарии 54

Характеристики:

Код открыт Не указано

Рубрики Тестирование QA

Кому Программист

Тип файла Нет файла

Платформа Не имеет значения

Конфигурация Не имеет значения

Операционная система Windows

Страна Не имеет значения

Отрасль Не имеет значения

Налоги Не имеет значения

Вид учета Не имеет значения

Доступ к файлу Бесплатно (free)