gifts2017

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

Опубликовал Пишу код как картины (yurii_host) в раздел Программирование - Практика программирования

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

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

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

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

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

Вот и все.

Дальше разберем варианты использования этой процедуры. Предположим, что мы тестируем некоторый общий модуль МойОбщийМодуль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. Получение значения внутренней переменной модуля

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

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

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Артур Аюханов (artbear) 17.11.15 09:24
Если вы пишете юнит-тесты, чтобы протестировать свой код, то, скорее всего, довольно часто сталкивались с необходимостью протестировать некоторую внутреннюю процедуру или функцию разрабатываемого модуля.

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

Всегда нужно тестировать именно поведение, т.е. публичный интерфейс, соответственно, публичные методы
zqzq; bforce; kuntashov; nSpirit2; kstukov; BorovikSV; JohnyDeath; pavlov_dv; theshadowco; caponid; Armando; adva; ardn; +13 Ответить 2
2. Артур Аюханов (artbear) 17.11.15 09:27
Использование "ВыполнитьВКонтексте" также зло :(
Пояснения (не в порядке важности)
  • Перестает работать встроенная подсказка 1С
  • Простой вызов Метод(Парам1, Парам2) превращается в сложный код из нескольких строк (создать массив, добавить параметры, вызов ВыполнитьВКонтексте
  • Появляется соблазн весь свой код выполнять в подобном ВыполнитьВКонтексте и получаем спагетти-код
  • Слишком универсальные методы это не всегда хорошо, нужно идти от бизнес-поведения, т.е. реализовывать публичный интерфейс/публичные бизнес-методы, которые и вызывать.
3. Игорь Пашутин (Alien_job) 17.11.15 09:59
Интересный ход. Иногда при программном заполнении каких-нибудь форм нужно вызывать код обработчиков событий, а они не экспортные. Подобным образом можно будет добраться и до них.
4. Юрий Былинкин (ardn) 17.11.15 10:25
(1) artbear,
Согласен.
Результат теста отдельной внутренней функции заключается только в том, что мы проверили именно эту функцию. Хорошо, она работает. Но может быть она вовсе не вызывается в каких то необходимых случаях, или параметры в нее передаются не те, что вы ожидаете.
Правильней тестировать программный интерфейс модулей или же вообще пользовательскую функциональность программы (автоматизированное тестирование от 1С) .
5. Пишу код как картины (yurii_host) 17.11.15 10:47
(1) artbear, тестирование внутренних функций не отменяет тестирование публичных.
Я конечно доверяю твоему опыту, и использую вашу разработку, а также внимательно слежу за развитием проекта xUnitFor1C. Но однако, прошу указать ссылку, где написано, что "тестирование внутренних методов это зло". Или может кто-нибудь из присоединившихся к этому высказыванию кинет ссылку на классику.

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

Юнит-тесты - это тестирование "маленьких" функций. А тестирование поведения - это уже приемочные тесты. Или я не прав?
Патриот; Alien_job; +2 1 Ответить 2
6. Пишу код как картины (yurii_host) 17.11.15 11:02
(2) artbear, согласен по поводу замечания насчет читаемости.
Делать методы публичными, чтобы только их протестировать - нарушение инкапсуляции, тоже некрасиво.
new_user; +1 Ответить
7. Sergey Andreev (starik-2005) 17.11.15 11:03
Мне тоже кажется, что данный метод - это зло. С другой стороны, тестирование позволяет найти не более 30% ошибок, при этом тестирование по эффективности в 5-10 раз хуже, чем инспекции кода и парное программирование (Макконнелл). Меняйте методы разработки и вам не придется "страдать" такой ерундой.
8. Евгений Сосна (pumbaE) 17.11.15 11:08
(7) starik-2005, просто с тестированием вы на этапе программирования эти 30% уже исправляете, а не в продакшине и хоть немного уверены, что у вас не будет регрессии.
9. Олег Николаев (o.nikolaev) 17.11.15 11:12
(5) Согласен. Я пишу и не для публичных методов тесты тоже.
10. Евгений Сосна (pumbaE) 17.11.15 11:17
(0) для безопасности советую или определенную роль добавить или же проверять константы тип имя базы, что-бы данный код не запустился на рабочей базе.
new_user; yurii_host; +2 Ответить 2
11. Пишу код как картины (yurii_host) 17.11.15 11:22
(10) pumbaE, абсолютно согласен. В целях безопасности следует адаптировать процедуру. Либо удалять ее при сборке конфигурации для продуктива (если хранится в git'e)
12. Артур Аюханов (artbear) 17.11.15 15:17
(5)
прошу указать ссылку, где написано, что "тестирование внутренних методов это зло

Почитай, например, http://sergeyteplyakov.blogspot.ru/2013/05/blog-post.html
или http://habrahabr.ru/post/224733/
или гуглить "тестирование приватных методов"
13. Артур Аюханов (artbear) 17.11.15 15:20
Юнит-тесты - это тестирование "маленьких" функций. А тестирование поведения - это уже приемочные тесты. Или я не прав?

Юнит-тесты также должны тестировать поведение, но только маленьких кусочков функциональностей.
мы же тестируем, чтобы гарантировать, что наш код выполняет свои обещания, т.е. отвечает за свое поведение.
14. Артур Аюханов (artbear) 17.11.15 15:23
И безопасность из (10)
и (2)
и соблазн быстро "наговнокодить" через ВыполнитьВКонтексте
и т.п.
15. Пишу код как картины (yurii_host) 17.11.15 15:56
(12) artbear, в статьях содержатся аргументы и "за" и "против".
из visual studio 2012 возможность тестирования закрытых методов видимо была удалена не случайно. НО вместо нее осталась возможность тестирования protected-методов.
Получается, что тестировать нужно, но не все подряд внутренние методы.

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

В общем и целом, делаю для себя вывод, что аргументов "против" - больше. И использование предложенной мной методики нежелательно. Однако такая возможность есть, и статью оставляю, для расширения кругозора, а также ради дискуссии, развернувшейся на основании нее.
16. Пишу код как картины (yurii_host) 17.11.15 15:59
Большое спасибо всем отписавшимся за конструктивную критику.
Было интересно и полезно услышать разные мнения.
mindcannon; aduyunov_2015; +2 Ответить
17. Sergey Andreev (starik-2005) 17.11.15 16:07
(8) pumbaE, в прожакшн попадает код после инспекций, которые сокращают время поиска багов в 3-4 раза и имеют эффективность поиска ошибок до 75%. В литературе инспекции описаны (я ссылке привел на автора). В IBM и многих других компаниях давно уже не занимаются тестированием - вместо этого проводят инспекции кода. И это является одним из обязательных условий достижения CMM 5 уровня.
18. Алексей Дуюнов (aduyunov_2015) 18.11.15 10:31
(4) ardn, на то оно и юнит тестирование, что проверяем отдельные функции. И да, дейстивтельно необходимо уметь писать правильные тесты.
и конечно это не отменяет тестирования поведения
19. Олег Николаев (o.nikolaev) 18.11.15 12:21
(17) starik-2005,
>> В IBM и многих других компаниях давно уже не занимаются тестированием
А где можно подробнее об этом почитать?
20. Sergey Andreev (starik-2005) 18.11.15 12:28
(19) o.nikolaev, в книге "Совершенный код" Макконнелла.

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

P.P.S.: юнит-тестирование выявляет проблемы в маленьком клочке нового кода, позволяя открыть все формы, закрыть их, провести каждый вид документа или сформировать каждый вид отчета по заранее заготовленному шаблону. Суммарные трудозатраты на поддержку актуального состояния юнит-тестов примерно в 3 раза больше, чем трудозатраты на регулярные инспекции. И если инспекции производятся в соответствии с рекомендациями по CMMi, то выявленные ошибки достигают 75%. Почти такого же эффекта достигает и парное программирование. Поэтому взаимопомощь разработчиков внутри проекта является элементом парного программирования и позволяет выявить большую часть проблем еще до релиза. и если помощь одного разработчика другому в компании пресекается (я с таким сталкивался), то качество продукта реально страдает.
21. rtnm rtnm (rtnm) 19.11.15 16:38
В таких языках программирования, например, как С#, если вы столкнулись с необходимостью протестировать private метод(кусочек внутренней логики) какого-нибудь класса, то у вас всегда есть 2 варианта:
- Реализовать этот метод как protected
- Вынести логику в отдельный внутренний(вложенный) класс
При этом клиенты изначального класса ничего не узнают об этих изменениях, и инкапсуляция будет сохранена.
А что делать в 1С?
Иногда бывают такие сложные функции, что тестировать их через перебор всех граничных состояний входов и выходов просто невозможно.
22. Armando Armando (Armando) 04.09.16 20:59
(3) Alien_job, серверные процедуры модулей форм можно вызывать даже если они не экспортные.
Форма = ПолучитьФорму(ПолноеИмяФормы);
Форма.ИмяСервернойПроцедуры();
u_n_k_n_o_w_n; artbear; Synoecium; yurii_host; +4 Ответить 2
23. Пишу код как картины (yurii_host) 05.09.16 00:09
(22) Armando, спасибо за подсказку.
Неожиданное поведение. Проверил, это действительно работает
24. Евгений Сосна (pumbaE) 05.09.16 09:05
(22) Armando, к сожалению, разработчики платформы уже в курсе об этом лайфхаке и обещали убрать в скором времени. (Надеюсь только для обработки ОписаниеОповещения)
25. Armando Armando (Armando) 05.09.16 10:42
(24) pumbaE, они не только в курсе, они даже на ИТС об этом написали, что надо учитывать эту особенность, и быть предельно осмотрительным.
26. Armando Armando (Armando) 05.09.16 10:44
(24) pumbaE, где обещали? Есть ссылка на тему на партнёрский?
27. Armando Armando (Armando) 05.09.16 11:18
28. Евгений Сосна (pumbaE) 05.09.16 11:56
(26) Armando, не совсем обещали, но надеяться на это не стоит.
Прикрепленные файлы:
29. Артур Аюханов (artbear) 06.09.16 20:25
(26) (28) Я даже статью на инфостарт писал об этом баге, но ее не приняли.
Пришлось на хабр выложить :) https://habrahabr.ru/post/273155/
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа