Как протестировать неэкспортные процедуры модулей

17.11.15

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

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

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

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

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

Процедура ВыполнитьВКонтексте(Команда, Параметр=Неопределено) Экспорт
	Выполнить(Команда);
КонецПроцедуры

Вот и все.

Дальше разберем варианты использования этой процедуры. Предположим, что мы тестируем некоторый общий модуль МойОбщийМодуль1

 

1. Вызов процедуры без параметров.

Пусть в тестируемом модуле есть процедура 

Процедура МояПроцедура0()
КонецПроцедуры

Вызов этой процедуры извне будет выглядеть так:

МойОбщийМодуль1.ВыполнитьВКонтексте("МояПроцедура0()");

 

2. Вызов процедуры с одним параметром

Пусть в тестируемом модуле есть процедура 

Процедура МояПроцедура1(ВходнойПараметр)
КонецПроцедуры

Вызов этой процедуры извне будет выглядеть так:

ЗначениеПараметра = "Некоторое_значение";
МойОбщийМодуль1.ВыполнитьВКонтексте("МояПроцедура1(Параметр)", ЗначениеПараметра);

 

3. Вызов процедуры с несколькими параметрами

Пусть в тестируемом модуле есть процедура 

Процедура МояПроцедура2(ВходнойПараметр1, ВходнойПараметр2)
КонецПроцедуры

Вызов этой процедуры извне будет выглядеть так:

МассивПараметров = Новый Массив;
МассивПараметров.Добавить("Некоторое_значение1");
МассивПараметров.Добавить("Некоторое_значение2");
МойОбщийМодуль1.ВыполнитьВКонтексте("МояПроцедура2(Параметр[0], Параметр[1])", МассивПараметров);

Вместо массива в этом варианте можно использовать структуру

 

4. Вызов функции без параметров

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

Функция МояФункция0()
КонецФункции

Вызов этой функции извне будет выглядеть так

РезультатФункции = Неопределено; // сначала объявим переменную, в которую будем возвращать значение
МойОбщийМодуль1.ВыполнитьВКонтексте("Параметр = МояФункция0()",РезультатФункции);

 

5. Вызов функции с параметрами

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

Функция МояФункция1(ВходнойПараметр)
КонецФункции

Вызов этой функции извне может выглядеть так

ПараметрФункции = "Передаваемый_параметр";
МойОбщийМодуль1.ВыполнитьВКонтексте("Параметр = МояФункция1(Параметр)",ПараметрФункции);
РезультатФункции = ПараметрФункции;

 

6. Получение значения внутренней переменной модуля

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

Сделать это можно по аналогии с предыдущими пунктами

тесты юнит-тесты тестирование отладка

См. также

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

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

2160 руб.

20.01.2022    8334    29    0    

14

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

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

3000 руб.

05.08.2024    1823    17    1    

11

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

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

2400 руб.

04.07.2022    8863    39    1    

30

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

Чтобы обеспечить высокое качество тиражной конфигурации 1С, ручного тестирования недостаточно – нужно учесть множество комбинаций функциональных опций, группы доступа и влияние подсистем друг на друга. Расскажем о промышленном тестировании флагманского продукта 1С:ERP и его дочерних конфигураций.

31.01.2025    4206    Pr-Mex    27    

28

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

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

21.01.2025    995    Sergey1CSpb    6    

4

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

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

16.01.2025    755    1C_Community    9    

4

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

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

28.11.2024    2943    user1999010    3    

18

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

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

31.10.2024    1749    capitan    0    

0
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. artbear 1566 17.11.15 09:24 Сейчас в теме
Если вы пишете юнит-тесты, чтобы протестировать свой код, то, скорее всего, довольно часто сталкивались с необходимостью протестировать некоторую внутреннюю процедуру или функцию разрабатываемого модуля.

Тестировать приватную/внутреннюю функцию - это зло :(
Если тестировать внутреннюю функциональность, можно нарушить состояние объекта.

Всегда нужно тестировать именно поведение, т.е. публичный интерфейс, соответственно, публичные методы
zqzq; bforce; kuntashov; nSpirit2; kstukov; BorovikSV; JohnyDeath; pavlov_dv; theshadowco; caponid; Armando; adva; ardn; +13 Ответить
4. ardn 683 17.11.15 10:25 Сейчас в теме
(1) artbear,
Согласен.
Результат теста отдельной внутренней функции заключается только в том, что мы проверили именно эту функцию. Хорошо, она работает. Но может быть она вовсе не вызывается в каких то необходимых случаях, или параметры в нее передаются не те, что вы ожидаете.
Правильней тестировать программный интерфейс модулей или же вообще пользовательскую функциональность программы (автоматизированное тестирование от 1С) .
18. aduyunov_2015 18.11.15 10:31 Сейчас в теме
(4) ardn, на то оно и юнит тестирование, что проверяем отдельные функции. И да, дейстивтельно необходимо уметь писать правильные тесты.
и конечно это не отменяет тестирования поведения
5. json 3359 17.11.15 10:47 Сейчас в теме
(1) artbear, тестирование внутренних функций не отменяет тестирование публичных.
Я конечно доверяю твоему опыту, и использую вашу разработку, а также внимательно слежу за развитием проекта xUnitFor1C. Но однако, прошу указать ссылку, где написано, что "тестирование внутренних методов это зло". Или может кто-нибудь из присоединившихся к этому высказыванию кинет ссылку на классику.

У Роберта Мартина "Чистый код" написано обратное. Он наоборот пишет тесты на каждую функцию.

Юнит-тесты - это тестирование "маленьких" функций. А тестирование поведения - это уже приемочные тесты. Или я не прав?
Vovan58; Патриот; Alien_job; +3 1 Ответить
9. o.nikolaev 216 17.11.15 11:12 Сейчас в теме
(5) Согласен. Я пишу и не для публичных методов тесты тоже.
12. artbear 1566 17.11.15 15:17 Сейчас в теме
(5)
прошу указать ссылку, где написано, что "тестирование внутренних методов это зло

Почитай, например, http://sergeyteplyakov.blogspot.ru/2013/05/blog-post.html
или http://habrahabr.ru/post/224733/
или гуглить "тестирование приватных методов"
15. json 3359 17.11.15 15:56 Сейчас в теме
(12) artbear, в статьях содержатся аргументы и "за" и "против".
из visual studio 2012 возможность тестирования закрытых методов видимо была удалена не случайно. НО вместо нее осталась возможность тестирования protected-методов.
Получается, что тестировать нужно, но не все подряд внутренние методы.

По поводу "возникает соблазн быстро "наговнокодить" через ВыполнитьВКонтексте" - абсолютно согласен.

В общем и целом, делаю для себя вывод, что аргументов "против" - больше. И использование предложенной мной методики нежелательно. Однако такая возможность есть, и статью оставляю, для расширения кругозора, а также ради дискуссии, развернувшейся на основании нее.
2. artbear 1566 17.11.15 09:27 Сейчас в теме
Использование "ВыполнитьВКонтексте" также зло :(
Пояснения (не в порядке важности)
  • Перестает работать встроенная подсказка 1С
  • Простой вызов Метод(Парам1, Парам2) превращается в сложный код из нескольких строк (создать массив, добавить параметры, вызов ВыполнитьВКонтексте
  • Появляется соблазн весь свой код выполнять в подобном ВыполнитьВКонтексте и получаем спагетти-код
  • Слишком универсальные методы это не всегда хорошо, нужно идти от бизнес-поведения, т.е. реализовывать публичный интерфейс/публичные бизнес-методы, которые и вызывать.
6. json 3359 17.11.15 11:02 Сейчас в теме
(2) artbear, согласен по поводу замечания насчет читаемости.
Делать методы публичными, чтобы только их протестировать - нарушение инкапсуляции, тоже некрасиво.
new_user; +1 Ответить
3. Alien_job 191 17.11.15 09:59 Сейчас в теме
Интересный ход. Иногда при программном заполнении каких-нибудь форм нужно вызывать код обработчиков событий, а они не экспортные. Подобным образом можно будет добраться и до них.
22. Armando 1402 04.09.16 20:59 Сейчас в теме
(3) Alien_job, серверные процедуры модулей форм можно вызывать даже если они не экспортные.
Форма = ПолучитьФорму(ПолноеИмяФормы);
Форма.ИмяСервернойПроцедуры();
u_n_k_n_o_w_n; artbear; Synoecium; json; +4 Ответить
23. json 3359 05.09.16 00:09 Сейчас в теме
(22) Armando, спасибо за подсказку.
Неожиданное поведение. Проверил, это действительно работает
24. pumbaE 05.09.16 09:05 Сейчас в теме
(22) Armando, к сожалению, разработчики платформы уже в курсе об этом лайфхаке и обещали убрать в скором времени. (Надеюсь только для обработки ОписаниеОповещения)
25. Armando 1402 05.09.16 10:42 Сейчас в теме
(24) pumbaE, они не только в курсе, они даже на ИТС об этом написали, что надо учитывать эту особенность, и быть предельно осмотрительным.
26. Armando 1402 05.09.16 10:44 Сейчас в теме
(24) pumbaE, где обещали? Есть ссылка на тему на партнёрский?
28. pumbaE 05.09.16 11:56 Сейчас в теме
(26) Armando, не совсем обещали, но надеяться на это не стоит.
Прикрепленные файлы:
29. artbear 1566 06.09.16 20:25 Сейчас в теме
(26) (28) Я даже статью на инфостарт писал об этом баге, но ее не приняли.
Пришлось на хабр выложить :) https://habrahabr.ru/post/273155/
pallid; Armando; +2 Ответить
27. Armando 1402 05.09.16 11:18 Сейчас в теме
7. starik-2005 3098 17.11.15 11:03 Сейчас в теме
Мне тоже кажется, что данный метод - это зло. С другой стороны, тестирование позволяет найти не более 30% ошибок, при этом тестирование по эффективности в 5-10 раз хуже, чем инспекции кода и парное программирование (Макконнелл). Меняйте методы разработки и вам не придется "страдать" такой ерундой.
8. pumbaE 17.11.15 11:08 Сейчас в теме
(7) starik-2005, просто с тестированием вы на этапе программирования эти 30% уже исправляете, а не в продакшине и хоть немного уверены, что у вас не будет регрессии.
17. starik-2005 3098 17.11.15 16:07 Сейчас в теме
(8) pumbaE, в прожакшн попадает код после инспекций, которые сокращают время поиска багов в 3-4 раза и имеют эффективность поиска ошибок до 75%. В литературе инспекции описаны (я ссылке привел на автора). В IBM и многих других компаниях давно уже не занимаются тестированием - вместо этого проводят инспекции кода. И это является одним из обязательных условий достижения CMM 5 уровня.
19. o.nikolaev 216 18.11.15 12:21 Сейчас в теме
(17) starik-2005,
>> В IBM и многих других компаниях давно уже не занимаются тестированием
А где можно подробнее об этом почитать?
20. starik-2005 3098 18.11.15 12:28 Сейчас в теме
(19) o.nikolaev, в книге "Совершенный код" Макконнелла.

P.S.: на всякий случай хочу пояснить, что тестирование достаточно больших программных комплексов подразумевает сборку релиза в течение достаточно длительного времени. При тестировании происходит визуальный контроль работы функционала, который не позволяет выявить большую часть проблем. Тестирование позволяет увидеть явный баг кода и в этом плане уходит не дальше, чем просто проверка на компилируемость. В то же время альфа- и бета-тестирование на реальной аудитории позволяет выявить большое количество ошибок (бета-тестирование в 1000 и более организаций - от 97%). Но это фактически использование продукта в стадии beta, когда его не используют в продакшн, а просто смотрят, как оно работает (типа установки новой платформы 1С и откат впоследствии к старой, ибо на продакте выявляются такие баги, о которых на стадии бететеста тестовой версии платформы никто не подумал или, обнаружив, не сообщил в 1С). Краудсорсинг в последнее время используется всеми большими компаниями. Та же W10, обновление на которую изначально прорекламировали, как чуть ли не амнистия пиратским копиям. Из-за этого бета винды и отправляла гигабайты данных в M$, что послужило поводом даже для разбирательства в суде на тему "слежения за пользователями".

P.P.S.: юнит-тестирование выявляет проблемы в маленьком клочке нового кода, позволяя открыть все формы, закрыть их, провести каждый вид документа или сформировать каждый вид отчета по заранее заготовленному шаблону. Суммарные трудозатраты на поддержку актуального состояния юнит-тестов примерно в 3 раза больше, чем трудозатраты на регулярные инспекции. И если инспекции производятся в соответствии с рекомендациями по CMMi, то выявленные ошибки достигают 75%. Почти такого же эффекта достигает и парное программирование. Поэтому взаимопомощь разработчиков внутри проекта является элементом парного программирования и позволяет выявить большую часть проблем еще до релиза. и если помощь одного разработчика другому в компании пресекается (я с таким сталкивался), то качество продукта реально страдает.
10. pumbaE 17.11.15 11:17 Сейчас в теме
(0) для безопасности советую или определенную роль добавить или же проверять константы тип имя базы, что-бы данный код не запустился на рабочей базе.
new_user; json; +2 Ответить
11. json 3359 17.11.15 11:22 Сейчас в теме
(10) pumbaE, абсолютно согласен. В целях безопасности следует адаптировать процедуру. Либо удалять ее при сборке конфигурации для продуктива (если хранится в git'e)
14. artbear 1566 17.11.15 15:23 Сейчас в теме
И безопасность из (10)
и (2)
и соблазн быстро "наговнокодить" через ВыполнитьВКонтексте
и т.п.
13. artbear 1566 17.11.15 15:20 Сейчас в теме
Юнит-тесты - это тестирование "маленьких" функций. А тестирование поведения - это уже приемочные тесты. Или я не прав?

Юнит-тесты также должны тестировать поведение, но только маленьких кусочков функциональностей.
мы же тестируем, чтобы гарантировать, что наш код выполняет свои обещания, т.е. отвечает за свое поведение.
16. json 3359 17.11.15 15:59 Сейчас в теме
Большое спасибо всем отписавшимся за конструктивную критику.
Было интересно и полезно услышать разные мнения.
mindcannon; aduyunov_2015; +2 Ответить
21. rtnm 616 19.11.15 16:38 Сейчас в теме
В таких языках программирования, например, как С#, если вы столкнулись с необходимостью протестировать private метод(кусочек внутренней логики) какого-нибудь класса, то у вас всегда есть 2 варианта:
- Реализовать этот метод как protected
- Вынести логику в отдельный внутренний(вложенный) класс
При этом клиенты изначального класса ничего не узнают об этих изменениях, и инкапсуляция будет сохранена.
А что делать в 1С?
Иногда бывают такие сложные функции, что тестировать их через перебор всех граничных состояний входов и выходов просто невозможно.
Оставьте свое сообщение