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

Публикация № 326820

Разработка - Практика программирования

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

 

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

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

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

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

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

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

 

 

 

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

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

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

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

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

 

 

 

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

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

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. Дальше я укажу те системы, которые я сам реально использовал, с которых мое знакомство с системами тестирования для 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С молчит по этому поводу.

 

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

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

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

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

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

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

Выводы:

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

Литература

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

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

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

Специальные предложения

Лучшие комментарии
50. artbear 1303 07.10.16 20:40 Сейчас в теме
(49) Можешь писать здесь.
Можешь создавать issue на проекте, как ты сегодня и сделал.
Можешь писать в официальном чате https://gitter.im/xDrivenDevelopment/xUnitFor1C

2 последних варианта предпочтительнее.
Остальные комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. zorka-gold 09.02.15 14:16 Сейчас в теме
Много битых (не рабочих) ссылок !
Andris_infostart; +1 1 Ответить
2. artbear 1303 09.02.15 16:13 Сейчас в теме
(1) Ага, есть такое, все-таки выступление двухлетней давности.
Ссылки поправлю в ближайшее время.
3. artbear 1303 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 726 09.02.15 19:04 Сейчас в теме
Есть метод белого ящика – то есть, мы опять же знаем, что у нас внутри, как организован проект, какие идут связи и можем более точно построить тесты, например, предположить, что на каких-то граничных условиях наши тесты могут падать.
Специально обученные отделы тестирования, крайне не любят данный метод. Говорят, что он только сбивает.
8. artbear 1303 10.02.15 13:32 Сейчас в теме
(4) Белый ящик не всегда плох, как раз на знании особенностей реализации можно доп.тесты написать, которые помогут.
Черный ящик плох тем, что внутренностей не знаем, и не знаем подводных камней.
19. awk 726 16.02.15 23:06 Сейчас в теме
(8) тестировщику и не надо знать. Программисту - наверное надо.
21. artbear 1303 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С. Сказать, что это изменило мой стиль разработки - не сказать ничего, это буквально перевернуло устоявшийся и "закостеневший" за годы процесс. Натыкался до НГ на упомянутый проект на гитхабе, разбирался, хотел присоединиться к разработке, но потом НГ, отчетность, дела, обучение, как обычно, короче, толком в курс не вошёл. В статье упомянуто про "видеотренинги и видео-примеры", где их можно посмотреть, киньте ссылкой плз.
pt_olga; slazzy; lustin; +3 Ответить
6. artbear 1303 09.02.15 23:45 Сейчас в теме
9. slazzy 41 10.02.15 15:12 Сейчас в теме
(6), Можно позадавать Вам пару вопросов по ходу обдумывания материала? :)

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

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

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


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


К тому же судя по-всему к 1С это вообще слабо применимо. Это в СИ какой-нибудь кусок памяти видимо может быть изменен другой программой и произойдет какая-нибудь непредвиденная ошибка. В 1С же практически существует конечный пул ошибок и почти всегда их можно предусмотреть и проверить. По сути в 1С и так предостаточно проверок и способов сделать эти проверки, да и сам язык довольно хорошо от них защищает.
10. artbear 1303 10.02.15 18:16 Сейчас в теме
(9) Механизм утверждений/assert-ов (не accert) предназначен именно для подтверждения контракта функции/процедуры и отличается от стандартных проверок параметров тем, что не возвращает некое значение в вызывающую функцию, а сразу выбрасывает исключение, прерывая выполнение кода!!
Это важный момент.
Фактически утверждение говорит о том, что заданы жесткое условие/состояние (инвариант), которому должны удовлетворять функция/процедура.
Здесь неважно, какое условие/контракт проверяется.
Например, можно проверять тип входного параметра, его значения и т.п.

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

По поводу скорости работы:
1. не допускайте преждевременной оптимизации. Как и в других языках, в 1С профайлер - главное мерило производительности, а не личные впечатления :)
2. как правило, проверки не бывают слишком сложными.
38. zqzq 21 25.03.15 16:30 Сейчас в теме
(6) посмотрел видео про змейку и прочее, очень познавательно, но... как-то от обычных 1С-ных задач далеко. В результате так и не очень понятно, как применять это TDD(Бека тоже почитал, но он работу с БД не любит и примеры с ООП не всегда гладко на 1С ложатся). В идеале нужно что-нибудь вроде примера решения задачи с 1С-ного билета по специалисту через тестирование.
40. artbear 1303 25.03.15 16:58 Сейчас в теме
(38) Пример со змейкой дает возможность просто и в игровой форме показать самые базовые приемы работы через ТДД.
У нас на подготовку змейки ушел не один день.
По реальным примерам:
если делать сложную разработку, слишком много времени это займет. а реальной пользы будет мало
Для начинающих сразу не нужно пытаться делать большую разработку с помощью тестов.
я предпочитаю двигаться по шагам, от деталей к общему.

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

ОФФ. что-то Инфостарт совсем перестал информировать о новых сообщениях в моей же ветке :(
42. zqzq 21 26.03.15 09:02 Сейчас в теме
(40) на сайте 1с есть пример билета и каркасная конфигурация:
http://www.1c.ru/rus/partners/training/questions.htm
Можно взять первую задачу - оперативный учет. На экзамене на неё отводится примерно 60-90 минут. По-моему, она сильно ближе к реальным 1с-овским задачам, чем змейка, а вот как подступиться с помощью 1с-ТДД непонятно (действительно, может не 1 день занять, особенно с непривычки).
lenna1c; Quasar; Mos; +3 Ответить
7. lustin 10.02.15 06:51 Сейчас в теме
(5) baloo, вот за RoR отдельное спасибо - мы в процессе работы очень много вдохновения именно оттуда черпаем. И да - "мозг меняется".
11. sergei2k 10.02.15 19:08 Сейчас в теме
Конфигурация "Сценарное тестирование" поддерживает создание и выполнение тестов с использованием нового механизма платформы.
Но, сам механизм работает с ошибками (например, не записывает выбор панели функций раздела), и очень последовательность действий пользователя при записи сценария должна быть очень продуманной.
12. artbear 1303 10.02.15 19:35 Сейчас в теме
(11) Напоминаю, что это выступление 2012 года.
Тогда еще не было продукта сценарное тестирование для упр.приложения.
Согласен, что есть много сложностей при разработке таких тестов.
Например, ребята недавно нарвались на вылет 1С при попытке записи действий пользователя, если не была открыта ни одна форма.
несколько последних платформ 8.3.5 тупо падают.
стоит только открыть какую-то форму, а уж потом запустить запись, 1С нормально работает.
В общем, проблем масса.

Когда я осенью 2012 года был на партнерской конференции в Москве, в Космосе, специально подходил к разработчикам сценарного тестирования.
Они показывали как раз сценарное тестирования для упр.приложений, внутреннюю альфа-версию
Они мне сообщили, что на тот момент им неизвестно о тестировании продуктов упр.приложения (УТ 11, УНФ и др.) средствами автотестирования 8.3 :(
13. so-quest 133 11.02.15 10:59 Сейчас в теме
http://infostart.ru/public/22168/ ничего интересного из себя не представляет.

https://github.com/wwall/xUnitFor1C - тут добавлена поддержка проверки равенства структур. Может кому потребуется
14. artbear 1303 11.02.15 11:58 Сейчас в теме
(13) ты бы это как-нибудь документировал для понимания сторонними разработчиками.
А я бы тогда подумал о включении в основной xUnitFor1C :)
15. AlexSunS 15.02.15 17:34 Сейчас в теме
Как много веяний "новых" на ИС.
16. artbear 1303 16.02.15 01:02 Сейчас в теме
В Вики xUnitFor1C я документировал пример готового теста проверки отчета на СКД.
В тесте сначала создаются тестовые данные в базе, затем выполняется отчет на СКД, получается сводная таблица.
Эта таблица сверяется с эталоном.
JohnyDeath; +1 Ответить
17. minimajack 73 16.02.15 20:13 Сейчас в теме
(16) лишнее
юТест.ПроверитьБольше(ТестовыеДанные.Количество(), 0, "Ожидали, что загрузка макета загрузит данные больше 0");

вы же не юнит-тестирвание проверяете
18. pumbaE 641 16.02.15 20:31 Сейчас в теме
(17) 1с и чистый юнит-тест не совсем совместимы.
22. minimajack 73 17.02.15 08:02 Сейчас в теме
(18) pumbaE, (20)
имхо:
я к тому что "ПроверитьБольше" - это "от черта".
либо равенство количеству строк (количество = 5), либо равенство на булево ( количество > 0 )...
само по себе "больше" не помогает в тестировании, а наоборот помогает скрыть ошибки, т.к. проще написать больше 0 и забить
23. artbear 1303 17.02.15 19:32 Сейчас в теме
(22) ты прав, а мы внимания не обратили.
ПроверитьБольше здесь от "лукавого"
В Вики поправил, вообще удалив эту ненужную строку.
Спасибо!
24. pumbaE 641 18.02.15 09:12 Сейчас в теме
(22) minimajack, не соглашусь. Не в данном случаи, а в общем. ПроверитьБольше дает большее представление об ошибке чем "проверить(Количичество()>0) ", сразу видно что передано, параметр 1=0, параметр2(проверки) = 0 и уже в пояснении достаточно написать просто "ТЧ Товары.Количество()". В случаи же проверки истины, нам в пояснении надо писать "ТЧ Товары.Количество() = 0" и т.д., повторять тот же код, который мы пытались проверить.
25. artbear 1303 18.02.15 10:14 Сейчас в теме
(24) Женя, я лично считал, что в (22) говорится о ПроверитьНеРавенство(0, Таб.Количество()) или ПроверитьРавенство(5, Таб.Количество())
ПроверитьИстина(Таб.Количество() > 0) или ПроверитьИстина(Таб.Количество() = 5) явно плохо.
26. minimajack 73 18.02.15 12:24 Сейчас в теме
(24) pumbaE, по идее в тестах мы заранее знаем точное значение ожидаемого результата, и именно это значение надо использовать как написано в 25, если это невозможно использовать ( а это очень и очень маловероятно...по крайней мере в 1С8 без ВК и внешних сервисов) - использовать ПроверитьИстина(Таб.Количество() > 5) с описанием ошибки вручную - вплоть до ссылки на описание почему именно это значение.
Пример:
один и тот же набор данных используется при тестировании двух отчетов. Изменяют первый отчет(вывод дополнительных данных, новый тип операции и т.п.) -> меняют исходные данные (тестовый файл) -> меняют тест по первому отчету -> все ок; при этом второй отчет на ошибке ПроверитьБольше 0 все также будет проходить, но не факт что результат отчета будет идентичный. Если бы стояло ПроверитьРавенство(5, Таб.Количество()) - ошибка сразу стала бы известна - именно на этапе загрузки данных, а не по факту. То есть найти ошибку будет проще. И именно поэтому, я написал "помогает скрыть ошибки".
ПроверитьНеРавенство(0, Таб.Количество()) - аналогично скроет ошибку.
Использовать скрытое сравнение как ПроверитьИстина(Таб.Количество() = 5) - тоже плохо, как минимум тем что используется не по назначению и неудобно для рефакторинга.
ИМХО оптимальный ПроверитьРавенство(5, Таб.Количество()) - дает наиболее точный результат
В общем все это мое личное мнение. Я никого не принуждаю писать код именно так, просто исходя из своего опыта даю рекомендации.
27. artbear 1303 18.02.15 15:24 Сейчас в теме
(26) Да, согласен, что ПроверитьРавенство(5, Таб.Количество()) наиболее оптимально.
пара уточнений:
  • лучше писать ПроверитьРавенство(5, Таб.Количество(), "Таб.Количество()") или ПроверитьРавенство(5, Таб.Количество(), "количество созданных объектов")
  • ИМХО лучше вообще исключить эту проверку, как я сделал в Вики, т.к. в данном случае утверждение проверяет создание тест.данных, т.е. функционал, который вторичен для данной задачи. для этой задачи важно проверить именно соответствие результата отчета эталону, а не создание данных.
20. artbear 1303 16.02.15 23:38 Сейчас в теме
(17) Человек, который писал этот тест, еще не очень доверял методу юТест.СоздатьДанныеПоТабличномуДокументу :)
Поэтому и вставил подобную проверку для гарантии правильности теста.
А этот метод, как и многие в xUnitFor1C, либо работает и возвращает данные при правильном макете, либо падает с исключением, если макет неверен.

Как уже отмечено в (18), в 1С очень зыбкая граница между юнит-тестами и приемочными тестами.
Я лично давно уже не говорю "юнит-тесты" в 1С, а упоминаю именно тесты.
28. eugeniezheludkov 33 06.03.15 07:06 Сейчас в теме
Воу, хорошая статья , видимо ранее плохо искал раз не натыкался на неё. довольно хорошо и понятно разжевано именно как это реализовать на 1С. на хЮнит1С стал по другому смотреть! с удивлением для себя обнаружил там вики :). еще заинтересовала подсистема (автор - Сергей Старых) – называется Подсистема «Инструменты разработчика».
Тему в закладки, буду пытаться поднять её у себя (сейчас тестированием реальные люди занимаются).. если получится то отпишусь как и что вышло. ранее не находил дельной инфы и считал проект "костылем", приношу извинения.
яб еще добавил "статический анализ кода" на каком - нибудь этапе после код-ревью , т.е когда анализируется структура кода на возможные ошибки и даже неоптимальные участки кода (по шаблонам) во всяком случае для себя я простенький написал: ни одна типовая конфа не проходит 2 шаблона: "неиспользуемые(забытые переменные)","Запросы в циклах" на УПП к примеру это более 7000 таких неоптимальных участка. (выкладывал тут)
29. pumbaE 641 06.03.15 10:57 Сейчас в теме
(28) eugeniezheludkov, автоматизированя проверка конфигураций. Там есть попытка статистического анализа кода, но у меня терпения не хватает каждый раз ее проходить, видно в 1с та-же проблема.
p.s.: когда 90% кода типового, то к сожалению не всегда есть желание посмотреть на чужие ошибки, которые вряд-ли будешь исправлять или будут исправляться.
31. eugeniezheludkov 33 07.03.15 06:36 Сейчас в теме
(29) pumbaE, у меня анализ кода идет в ручном режиме. Внешняя обработка натравливается на выгруженные исходные коды всей конфы (шаблоны-регулярка) при этом чтоб отделить типовые объекты от своих, у нас правило: свои объекты имеют префикс. Проверяются объекты имеющие лишь этот префикс , результат выгружается в эксель, если исходники выгружались бы автоматом+гит+сервер сборок то впринципе эти шаблоны-регулярки могу легко перенеси в шарп, скорость проверки возрастет в разы
32. artbear 1303 07.03.15 11:28 Сейчас в теме
(31) Поделись кодом подобной проверки, очень интересно.
33. artbear 1303 07.03.15 11:32 Сейчас в теме
(32) Ага, увидел. Посмотрю, как сделано.
35. eugeniezheludkov 33 10.03.15 01:32 Сейчас в теме
(33) если что , тут последние коммиты , и сильно не пинайте за мои антипаттерны :( писал на коленке перед НГ
34. artbear 1303 07.03.15 11:33 Сейчас в теме
(31) А в чем проблема с реализацией автовыгрузки конфы на тексты? у нас давно реализовано - проект v83unpack
30. artbear 1303 06.03.15 14:17 Сейчас в теме
(28) (29) Да, пока только АПК остается.
Мы работаем над верификацией программ разными способами - синтакс-проверки, кросс-тестирование, автотесты, покрытие кода, код-ревью, АПК.
Минусы АПК (помимо скорости), о которых я говорил на общей стойке БСП/АПК на недавнем партнерском семинаре 1С - вся автоматизация внутри АПК, нет внешнего управления и возможности получения результатов проверки извне.
Мы пользуемся билд-серверами, они отлично себя показывают, и у меня в планах заставить АПК выполнять автопроверки именно через билд-серверы.
36. baloo 23.03.15 13:24 Сейчас в теме
По поводу проверки "Запросы в циклах" - у вас анализируется вызов в цикле процедур/функций, внутри которых совершается запрос? Кроме того, было бы здорово анализировать не только наличие явного исполнения запроса через запрос на встроенном языке запросов, но и обращение к реквизитам переменных ссылочного типа, что, по сути, влечет за собой неявное выполнение запроса к БД.
ПС обработку не видел, нисколько не критика - чисто размышления по улучшению :)
37. eugeniezheludkov 33 24.03.15 04:05 Сейчас в теме
(36) baloo, естественно анализируется вызов процедур и функций и неявные запросы (типа .НайтиПоКоду()) и отсекаются закомментированные вызовы, и детектируется вызов запросов в рекурсивных функциях https://github.com/znsoft/external1CProgs/blob/master/src/СтатическийАнализ­Кода1с/Form/Форма/module тут можете глянуть исходный код модуля,
todo(если появится время):
-анализ вызываемых функций в другом модуле (к примеру вызов через точку от другого объекта) сейчас такая функция не проверяется :( можно реализовать если просто строить таблицу вызовов функций первым проходом и анализ вызовов вторым проходом
-анализировать обращение к реквизитам переменных ссылочного типа (чет я про них и забыл то сам сколько раз по молодости обжигался :) спасибо за подсказку)
-убрать проверку неиспользуемых переменных т.к такая проверка есть в конфигураторе :)

сейчас времени не очень много (много ТЗ в очереди), все мечтаю рефакторить обработку и вообще переделать на шарп (мой фаворит) или на java для будущих версий 1С :)
39. artbear 1303 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 1303 25.03.15 19:42 Сейчас в теме
В дополнение к (39) см. (16)
Продублирую:
В Вики xUnitFor1C я документировал пример готового теста проверки отчета на СКД (со скриншотами и готовым кодом).
В тесте сначала создаются тестовые данные в базе, затем выполняется отчет на СКД, получается сводная таблица.
Эта таблица сверяется с эталоном.
43. kraynev-navi 492 20.11.15 15:44 Сейчас в теме
Подниму тему.
А можно как-то автоматизировать ввод названий тестов? Или может уже реализовано, не нашел?
Ну типа так:
Перем юТест;

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

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

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

Процедура Тест_ДваПлюсДва() Экспорт
	
	юТест.Проверить(2 + 2 = 4, "Значение не верно");
	
КонецПроцедуры
Процедура Тест_ДваПлюсТри() Экспорт
	
	юТест.Проверить(2 +3 = 4, "Значение не верно");
	
КонецПроцедуры
Показать
44. artbear 1303 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 492 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 1303 27.11.15 11:12 Сейчас в теме
(45) Тест открытия формы запускает свою транзакцию.
Насколько я понимаю, константа фиксируется в какой-то внутренней транзакции, которая возникает при проверке формы "Справочник.Организации.Форма.ФормаОрганизации"
В итоге получается вложенная транзакция, результаты которой откатываются при завершении тестов.
47. nicxxx 239 07.10.16 16:19 Сейчас в теме
ветка жива еще? на гитхабе созданный тикет удалился через минуту, поэтому спрошу здесь: в тонком клиенте 8.2 можно как-нибудь запустить обработку xddTestRunner? версия 4.1.0.0 выдает ошибку "Тип не определен (ОписаниеОповещения)", потому что в этой версии платформы (8.2.19.83) еще нет такого объекта языка.
в обычном приложении обработка открывается.
48. pumbaE 641 07.10.16 16:48 Сейчас в теме
(47) nicxxx, почитайте https://github.com/xDrivenDevelopment/xUnitFor1C/releases там есть такой текст
4.0.0.7 последний релиз для 8.2
49. nicxxx 239 07.10.16 18:05 Сейчас в теме
да, спасибо, я уже видел письмо с ответом.
А где все-так более живое обсуждение проекта идет? здесь все утихло, судя по тому, что последнее сообщение было 11 мес назад.
У меня есть пара вопросов, по концептуальным возможностям этой обработки, хочется выяснить перед тем, как начинать углубленное изучение.
50. artbear 1303 07.10.16 20:40 Сейчас в теме
(49) Можешь писать здесь.
Можешь создавать issue на проекте, как ты сегодня и сделал.
Можешь писать в официальном чате https://gitter.im/xDrivenDevelopment/xUnitFor1C

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


52. artbear 1303 13.01.17 15:58 Сейчас в теме
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, какие именно инструменты (возможно в связке) они используют?
Оставьте свое сообщение

См. также

Звуковое управление в 1С 8.3 Промо

Практика программирования v8 1cv8.cf Бесплатно (free)

В данной статье описано создание библиотеки для звукового управления (выполнение команд голосом) для платформы 1С 8.3. Задача была поставлена так, чтобы модуль функционировал непосредственно на клиенте 1С, осуществляя управление формами, и взаимодействовал с интерфейсом.

16.03.2021    2671    velemir    28    

Полезные примеры СКД, ч.1

Практика программирования v8::СКД Бесплатно (free)

Подборка видео по решению различных задач в отчетах на СКД.

30.03.2021    4799    Neti    18    

Обзор полезных методов БСП 3.1.4

Практика программирования БСП (Библиотека стандартных подсистем) v8 1cv8.cf Бесплатно (free)

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

25.03.2021    11109    rayastar    45    

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

Практика программирования Методология управления разработкой Бесплатно (free)

Учебный курс по теории и практике программирования. Бесплатно. В виде структурированного текста. Статья 4. Эта статья посвящена причинам возникновения проблем с качеством кода и методикам их преодоления.

22.03.2021    848    Артано    5    

Serverless (Faas) в 1С. Создание и вызов Yandex Cloud Functions Промо

Универсальные функции Практика программирования v8 Бесплатно (free)

"Я не могу просто взять и скопировать код с гитхаба", "у нас 1С микросервисами окружена", "возможностей мало" - частые фразы 1С разработчиков. которым не хватает возможностей платформы в современном мире. Faas, конечно, история не новая, но нас сдерживало 152ФЗ и задержки по пингам. Для того, чтобы действительно использовать в 1С код, к примеру, на Python, надо было приложить усилия. Теперь всё намного проще - берём и используем.

28.12.2020    5121    comol    28    

Telegram бот на PHP

Практика программирования Бесплатно (free)

Сделаем простого Telegram бота на PHP.

01.03.2021    2466    John_d    8    

«Варп-двигатель» для «среза последних»

Практика программирования Бесплатно (free)

Решение, позволяющее получить данные, аналогичные "срезу последних" на два порядка быстрее.

10.08.2020    3366    hobi    47    

1С: Документооборот, Data Science и Python

Документооборот и делопроизводство Математика и алгоритмы ДО Бесплатно (free)

В статье рассказывается о создании и обучении модели Data Science на языке Python и интеграции с системой 1С: Документооборот

04.08.2020    2609    Vaganov_Alexey    9    

Использование программных перечислений, ч.1: строковые константы Промо

Практика программирования v8 1cv8.cf Бесплатно (free)

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

10.12.2016    38857    unichkin    74    

Не спеша, эффективно и правильно – путь разработки. Часть 3. Практика

Практика программирования Бесплатно (free)

Черновой вариант книги Никиты Зайцева, a.k.a.WildHare. Разработкой на платформе 1С автор занимается с 1996-го года, специализация — большие и по-хорошему страшные системы. Квалификация “Эксперт”, несколько успешных проектов класса “сверхтяжелая”. Успешные проекты ЦКТП. Четыре года работал в самой “1С”, из них два с половиной архитектором и ведущим разработчиком облачной Технологии 1cFresh. Ну — и так далее. Не хвастовства ради, а понимания для. Текст написан не фантазером-теоретиком, а экспертом, у которого за плечами почти двадцать три года инженерной практики на больших проектах.

29.06.2020    11304    WildHare    33    

Не спеша, эффективно и правильно – путь разработки. Часть 2. Теория

Практика программирования Бесплатно (free)

Черновой вариант книги Никиты Зайцева, a.k.a.WildHare. Разработкой на платформе 1С автор занимается с 1996-го года, специализация — большие и по-хорошему страшные системы. Квалификация “Эксперт”, несколько успешных проектов класса “сверхтяжелая”. Успешные проекты ЦКТП. Четыре года работал в самой “1С”, из них два с половиной архитектором и ведущим разработчиком облачной Технологии 1cFresh. Ну — и так далее. Не хвастовства ради, а понимания для. Текст написан не фантазером-теоретиком, а экспертом, у которого за плечами почти двадцать три года инженерной практики на больших проектах.

22.06.2020    11640    WildHare    23    

Не спеша, эффективно и правильно – путь разработки. Часть 1. Парадигма

Практика программирования Бесплатно (free)

Черновой вариант книги Никиты Зайцева, a.k.a.WildHare. Разработкой на платформе 1С автор занимается с 1996-го года, специализация — большие и по-хорошему страшные системы. Квалификация “Эксперт”, несколько успешных проектов класса “сверхтяжелая”. Успешные проекты ЦКТП. Четыре года работал в самой “1С”, из них два с половиной архитектором и ведущим разработчиком облачной Технологии 1cFresh. Ну — и так далее. Не хвастовства ради, а понимания для. Текст написан не фантазером-теоретиком, а экспертом, у которого за плечами почти двадцать три года инженерной практики на больших проектах.

15.06.2020    17588    WildHare    34    

Вспомогательные инструкции в коде 1С Промо

Практика программирования v8 1cv8.cf Бесплатно (free)

Помогаем редактору кода 1С помогать нам писать и анализировать код.

15.10.2018    32610    tormozit    105    

Применение математических достижений в решении сложных задач бизнеса

Математика и алгоритмы Бесплатно (free)

Как правило, самые сложные задачи решаются с точки зрения математики очень легко. Но чтобы найти правильное решение, важно понять бизнес-цель, которую достигает эта задача. О практическом применении математических достижений для эффективного решения сложных задач бизнеса на конференции Infostart Event 2019 Inception рассказал Дмитрий Мишнов.

25.05.2020    4066    Mishnov    17    

JSON в запросах DaJet QL

Практика программирования Бесплатно (free)

Практические примеры работы с JSON непосредственно в языке запросов. Перенос курсов валют между УТ и БП. Требуется SQL Server 2016 и выше.

24.04.2020    4178    zhichkin    6    

Визионное программирование

Практика программирования Бесплатно (free)

Новый способ программирования и его практическая демонстрация.

22.04.2020    4861    mkalimulin    111    

Оформление и рефакторинг сложных логических выражений Промо

Практика программирования v8 Россия Бесплатно (free)

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

20.09.2012    79725    tormozit    131    

Улучшение пооперационного планирования в 1С:ERP 2.4 внешними средствами

Математика и алгоритмы Производительность и оптимизация (HighLoad) Бесплатно (free)

Задача построения оптимального производственного расписания требует сравнения тысяч и десятков тысяч вариантов. Выполнять такие вычисления средствами платформы 1С Предприятие нецелесообразно. Как реализовать пооперационное планирование с использованием генетических алгоритмов и параллельных вычислений в докладе на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «ИНТЕХ» Сергей Сафаров.

02.03.2020    6124    ildarovich    8    

Использование машинного обучения для решения инцидентов. Практическое применение

Практика программирования Бесплатно (free)

Продолжаю (и заканчиваю) тему с автоматическим решением инцидентов. Перейдем от теории к практике.

25.02.2020    4596    Repich    9    

Использование машинного обучения для решения инцидентов

Практика программирования Бесплатно (free)

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

18.02.2020    7379    Repich    17    

Запись значения в поле ввода/формы со срабатыванием события ПриИзменении Промо

Практика программирования v8 1cv8.cf Россия Бесплатно (free)

Иногда возникает необходимость после записи значения в какое либо поле ввода/формы вызвать для него обработчик события ПриИзменении, а о вызове самого события приходится только мечтать. В этой статье приводится программный способ вызова этого события.

11.07.2007    50622    tormozit    48    

Программная работа с настройками СКД

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

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

27.01.2020    43107    ids79    26    

[СКД] Программное создание схемы компоновки данных

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Сделаем отчет на СКД полностью программно, без использования макета "схема компоновки данных".

15.01.2020    32508    John_d    22    

Часовой на страже логов

Практика программирования Инструментарий разработчика Бесплатно (free)

При поддержке решений, которые установлены у большого количества пользователей на различных системах, очень важно вовремя получать подробную информацию о возникших проблемах. О том, как собирать логи и анализировать полученные данные в трекере ошибок Sentry на конференции Infostart Event 2019 Inception рассказал Андрей Крапивин.

13.01.2020    8126    Scorpion4eg    8    

Как сделать из &НаКлиентеНаСервереБезКонтекста почти &НаКлиентеНаСервере Промо

Практика программирования v8 1cv8.cf Россия Бесплатно (free)

Как сделать метод формы, доступный на клиенте и на сервере одновременно, и сохранить при этом удобство разработки

10.09.2017    47480    tormozit    74    

Последовательности событий при проведении документа 1С. Шпаргалка + про формы + про расширения

Практика программирования v8 Россия Бесплатно (free)

Собрал информацию о событиях/подписках/расширениях в одном месте.

30.12.2019    25009    kuzyara    38    

Полезные процедуры и функции для программиста

Практика программирования Универсальные функции v8 1cv8.cf Россия Бесплатно (free)

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

07.10.2019    34244    HostHost    41    

Таблица значений. Нюансы

Практика программирования v8 Бесплатно (free)

Обзор некоторых аспектов использования общеизвестного инструмента 1С.

01.10.2019    42571    Yashazz    50    

Развитие 1С программиста Промо

Практика программирования Личная эффективность Бесплатно (free)

Делюсь своим опытом и видением развития 1С программиста.

17.10.2018    23079    pashamak    64    

СКД. Отчеты с картинками

Практика программирования Работа с интерфейсом v8::СКД 1cv8.cf Бесплатно (free)

Решение популярных кейсов с картинками в отчетах на СКД.

25.09.2019    26175    YPermitin    41    

[Шпаргалка] Программное создание элементов формы

Практика программирования Работа с интерфейсом v8 1cv8.cf Бесплатно (free)

Программное создание практически всех популярных элементов формы.

06.09.2019    72618    rpgshnik    70    

Агрегатные функции СКД, о которых мало кто знает

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Пользуетесь ли Вы всеми возможными агрегатными функциями, которые предоставляет система компоновки данных? Если Вы используете только: СУММА, КОЛИЧЕСТВО, МИНИМУМ, МАКСИМУМ, СРЕДНЕЕ, то эта статья для Вас.

05.09.2019    61109    ids79    55    

Выгрузка документа по условию Промо

Практика программирования Разработка v8 Бесплатно (free)

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

25.04.2019    16613    m-rv    2    

Приватный блокчейн и 1С популярно

Практика программирования Блокчейн Бесплатно (free)

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

02.09.2019    6519    mkalimulin    140    

Кодогенерация и метагенерация в 1С

Практика программирования Инструментарий разработчика Бесплатно (free)

В своем докладе на конференции INFOSTART EVENT 2018 EDUCATION Дмитрий Белозеров рассказал о разработке инструмента, позволяющего программно работать с метаданными 1С и писать скрипты для выполнения тех же действий, которые выполняет разработчик в конфигураторе –  с какими сложностями и нюансами пришлось столкнуться, и что получилось в итоге.

26.08.2019    9324    kirovsbis    28    

Отслеживание выполнения фонового задания

Практика программирования Универсальные функции Разработка v8 1cv8.cf Бесплатно (free)

Запуск фонового задания из модуля внешней обработки. Отслеживание выполнения задания в виде прогресса, расположенного на форме.

17.08.2019    37836    ids79    16    

Как прикрутить ГУИД к регистру сведений Промо

Практика программирования Перенос данных из 1C8 в 1C8 Разработка v8 Бесплатно (free)

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

16.04.2019    21212    m-rv    17    

Функции СКД: ВычислитьВыражение, ВычислитьВыражениеСГруппировкойМассив

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Подробное описание и использование внутренних функций системы компоновки данных: Вычислить, ВычислитьВыражение, ВычислитьВыражениеСГруппировкойМассив, ВычислитьВыражениеСГруппировкойТаблицаЗначений.

08.08.2019    114469    ids79    69    

Фоновое выполнение кода в 1С - это просто

Практика программирования v8 1cv8.cf Бесплатно (free)

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

02.08.2019    46737    avalakh    26    

СКД - наборы данных и связи между ними, создание собственной иерархии, вложенные отчеты

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Набор данных объект. Использование в схеме компоновки нескольких наборов данных. Различные варианты связи наборов: объединение, соединение. Использование иерархии в отчетах на СКД. Создание собственной иерархии, иерархия детальных записей. Использование вложенных схем в отчетах на СКД.

26.07.2019    81234    ids79    14    

Как сделать запрос на изменение данных Промо

Практика программирования v8 v8::Запросы 1cv8.cf Бесплатно (free)

В статье приведены особенности внутренней архитектуры и примеры работы с расширением языка запросов 1С.

01.06.2018    32949    m-rv    22    

Обработчики событий при записи объектов. Зачем и что за чем?

Математика и алгоритмы v8 Бесплатно (free)

Программисту, имеющему немного опыта на платформе 1С 8.3, бывает сложно разобраться: ПередЗаписью, ПриЗаписи, ПослеЗаписи, на сервере, на клиенте, в модуле формы, в модуле объекта.... Эта шпаргалка была создана в процессе обучения и реального опыта с целью разложить всё по полочкам, чтобы было четкое понимание в каком случае какой обработчик нужно использовать и в какой последовательности они запускаются при записи и проведении документов. Данная статья будет полезна в большей степени начинающим разработчикам. Но и опытным позволит освежить информацию, упорядочить её.

25.07.2019    79584    AlbinaAAA    33    

Как проводятся документы в типовых конфигурациях от 1С

Математика и алгоритмы Практика программирования Разработка v8::ОУ ERP2 УТ11 Россия УУ Бесплатно (free)

В свое время, когда только начинал шаги в 1С и изучал, как проводятся документы в конфигурациях на платформе 1С по книге "Разработка управляемого интерфейса" (Хрусталева Е.Ю.), и там были представлены примеры совсем далекие от того, как сейчас проводятся документы в современных конфигурациях от 1С.

24.07.2019    31346    skv_79    35    

СКД - использование расширений языка запросов, секция ХАРАКТЕРИСТИКИ

Инструментарий разработчика Практика программирования v8 v8::СКД Бесплатно (free)

Автоматическое и не автоматическое заполнение полей компоновки данных. Использование расширений языка запросов для СКД «{…}», секция ВЫБРАТЬ, секция ГДЕ, параметры виртуальных таблиц. Автоматизированное использование дополнительных данных в запросе: секция ХАРАКТЕРИСТИКИ.

17.07.2019    41285    ids79    27    

Метод формирования движений в типовых регистрах нетиповыми регистраторами Промо

Практика программирования v8 1cv8.cf Бесплатно (free)

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

05.12.2017    29010    itriot11    34    

Интеграция сценарного тестирования в процесс разработки

Практика программирования Инструментарий разработчика Бесплатно (free)

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

08.07.2019    9705    grumagargler    7    

"Меньше копипаста!", или как Вася универсальную процедуру писал

Практика программирования Разработка v8 v8::СКД 1cv8.cf Бесплатно (free)

Программист Вася разбирает подход создания универсальных методов на примере программного вывода СКД.

04.07.2019    20634    SeiOkami    50    

Создание отчетов с помощью СКД - основные понятия и элементы

Практика программирования Математика и алгоритмы v8 v8::СКД Бесплатно (free)

Основные принципы работы СКД. Понятия схемы компоновки и макета компоновки. Описание основных элементов схемы компоновки: наборы данных, поля, вычисляемые поля, ресурсы, параметры.

25.06.2019    62842    ids79    26    

Использование классов .Net в 1С для новичков Промо

Практика программирования Разработка внешних компонент Универсальные функции v7.7 v8 Бесплатно (free)

Руководство для новичков. Написав статью http://infostart.ru/public/238584/, я понял, что многие не понимают того, что написано. Поэтому в этой статье постараюсь более подробно остановиться на азах и без кода на вражеском языке (C#)

27.01.2016    79065    Serginio    113    

Многопоточное ускорение однопользовательских нагрузок в 1С + Microsoft SQL Server 2017

Практика программирования Производительность и оптимизация (HighLoad) v8 v8::Запросы Бесплатно (free)

Взаимодействие с Microsoft SQL Server нередко вызывает трудности у 1С-ников, а потому интересны любые моменты, связанные с его использованием. О своем опыте работы с новым SQL Server 2017 участникам конференции Infostart-2018 рассказал директор ООО «Аналитика софт» Дмитрий Дудин.

11.06.2019    27742    dmurk    146    

Регистры накопления. Структура хранения в базе данных

Практика программирования Разработка v8 1cv8.cf Бесплатно (free)

Структура хранения регистров накопления в базе данных для платформы 1С:Предприятие 8.x. Первая часть в серии публикаций.

16.05.2019    51785    YPermitin    30