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

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. Получение значения внутренней переменной модуля

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

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

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

См. также

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

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

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

2220 руб.

04.07.2022    6908    26    1    

24

Автотесты для типовых конфигураций Бухгалтерия предприятия КОРП 3.0 и Бухгалтерия предприятия 3.0 (vanessa automation)

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

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

1728 руб.

20.01.2022    6683    10    0    

9

Нагрузочное тестирование для определения производительности системы

Тестирование QA Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

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

10 стартмани

08.04.2024    1193    3    user1527257    1    

4

Выполнение тестов и обработка их результатов в 1С: Тестировщик

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

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

14.03.2024    1391    Koder_Line    1    

11

Создание и модификация тестов в 1С:Тестировщик

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

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

23.01.2024    704    Koder_Line    1    

4

Настройка Allure для Gitlab (self-hosted)

Тестирование QA Абонемент ($m)

Заметка о том, как использовать Allure с self-hosted Gitlab, чтобы быстро и с минимальными усилиями получить удобные отчёты о результатах тестирования и навигацию внутри них.

1 стартмани

11.01.2024    2241    comptr    4    

25

Анализ документов: свертка базы, автотесты, динамика роста базы

Статистика базы данных Инструментарий разработчика Тестирование QA Платформа 1С v8.3 1С:Управление торговлей 10 1С:Управление производственным предприятием Абонемент ($m)

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

3 стартмани

29.12.2023    1189    8    RustIG    5    

8

Быстрый старт в 1С: Тестировщик

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

В данной статье мы рассмотрим начало работы, установку и подключение программы системы 1С: Тестировщик, рабочую область.

14.12.2023    2163    Koder_Line    0    

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

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

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

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

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

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

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

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

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