0. Сурикат 264 22.07.19 14:19 Сейчас в теме

О Unit-тестах замолвите слово.Часть 1

Последнее время в контексте 1С очень много говорят о функциональном тестировании, BDD. А Unit-тестирование обходят стороной. Попробуем разобраться, для чего Unit-тестирование применять стоит.

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. sapervodichka 1708 22.07.19 14:45 Сейчас в теме
по быстрому можно такой обработкой протестить https://infostart.ru/public/1056811/
2. Сурикат 264 22.07.19 15:19 Сейчас в теме
(1)
Эта обработка проводит "дымовое тестирование". Такая возможность есть во многих фреймворках тестирования, которые указаны в статье

Её функционал несколько урезанный относительно аналогов - нельзя запускать на CI.
for_sale; zeegin; sapervodichka; artbear; +4 Ответить
3. sapervodichka 1708 22.07.19 15:36 Сейчас в теме
(2) спасибо))) главное, что она есть
4. artbear 1156 22.07.19 15:40 Сейчас в теме
(1) А эта Ваш набор обработок не является ли набором обработок из раздела ERP ?

уж очень функционал схож.

или я ошибаюсь?
5. artbear 1156 22.07.19 15:41 Сейчас в теме
(0) Спасибо за набор статей с практическими примерами по тестированию.

Отдельное спасибо за использование и популяризацию Ванесса-АДД - тесты кодом (например, юнит-тесты) все-также важны!
6. grumagargler 612 22.07.19 15:57 Сейчас в теме
Однозначно полезный материал, но вы пишите, что unit и сценарное дополняют друг-друга, а в статье делаете их противопоставление, сквозит мысль неудачного опыта сценарного тестирования :-)
Но это разные техники и подходы, и TDD заслуживает внимания само по себе, а не от обратного других методик.
7. Сурикат 264 22.07.19 18:34 Сейчас в теме
(6)
Целью статей было больше показать, что есть сценарии, в которых написание Unit-тестов позволит намного быстрее получить результат, чем при написании сценарных тестов.

Я сделал сравнение, потому что у меня сложилось мнение, что освоившие функциональное тестирование (которое благодаря удачным инструментам хорошо пошло в массы) категорично отметают модульное тестирование, не видят нишу его применения.

Вот я и попытался описать те ситуации, в которых unit-тест отлично себя показывает =) По крайней мере в моей практике =)
8. grumagargler 612 22.07.19 19:11 Сейчас в теме
(7)
написание Unit-тестов позволит намного быстрее получить результат, чем при написании сценарных тестов

Да, я именно к этому и прицепился. Понимаете, механики тестирования у обоих подходов настолько отличаются, что даже тестируя казалось бы одну и туже функцию бизнес-приложения, о взаимозаменяемости говорить сложно. Юнит тест гарантирует работу определенного алгоритма, а сценарный - процесса. Юниту не нужно проверять срабатывания подписок на события или наличие объекта в меню, а сценарному, если и нужно только веб-сервис проверить, не менее важным является и достижимость функции в рамках процесса. В общем, хочу заразить идеей, что выставлять преимущества подхода лучше отталкиваясь от задачи, а не от неэффективности какой-либо другой методики.
9. artbear 1156 22.07.19 19:28 Сейчас в теме
(8) В рамках 1С "настоящие" юнит-тесты слабо возможны, т.к. наши тесты не отделимы от самой конфигурации 1С, платформы, СУБД и т.п.

я лично давно перестал употреблять термин именно " юнит-тестов", а использую термин "приемочные тесты" или "тесты кодом".

Любые приемочные тесты (хоть кодом (хЮнит, Тестер), хоть через БДД) имеют практическое одинаковые строение, как обычно, 3A :)

вопрос в инструментарии, удобстве разработки, сопровождаемости и т.п.

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

лично я за последние годы практически не пишу тестов кодом, а использую возможности приемочного тестирования в виде БДД-сценариев.
при этом фактически работаю через механизмы ТДД/БДД.
10. ImHunter 161 23.07.19 07:20 Сейчас в теме
(9) А вот это я не понял:
В рамках 1С "настоящие" юнит-тесты слабо возможны, т.к. наши тесты не отделимы от самой конфигурации 1С, платформы, СУБД и т.п.

Речь о том, что тестируемый 1С-код редко когда бывает чисто unit-кодом? А чаще всего делает явные или неявные обращения за пределы модуля?
11. artbear 1156 23.07.19 10:34 Сейчас в теме
(10) в других языках программирования часто можно отделить бекграунд от самого класса и проверить только функциональность класса, например, не подключая СУБД, не вызывая веб-сервисы, какие-то конфигурационные действия и т.п.
В 1С с этим сложно, поле возможностей у нас поменьше.

всегда есть СУБД (файловая или настоящая), всегда есть платформа 1С, всегда есть конфигурации.

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

например, в большинстве случаев нет особого смысла абстрагироваться от объектной модели конфигурации, это усложняет логику.
12. Сурикат 264 23.07.19 10:53 Сейчас в теме
(9)

По сравнению с другими языками это действительно так.

Но ведь можно представить что: у каждого метода языка есть параметры и есть контекст. Контекст - это параметры сеанса и методы доступа к БД.
Каждый метод нуждается не в полном контексте, а только в его части (кроме чего-то сильно глобального). И вот эту часть мы и можем мокать, создавая очень обрезанные объекты. Легкие, не требующие понимания а какие проверки нужно выполнить, чтобы он вообще создался.

Есть скажем контрагент, у него обязательно ИНН, КПП, заполненное по определенным правилам. Но в моем методе мне не нужен ИНН и КПП, мне нужна ссылка на контрагента и флаг "Не работаем", к примеру. И вот для модульного теста я и создам этого контрагента, не думая вообще ни о чем другом.

Да, это не полностью позволит мне проверить функционал, да я не проверю что процесс дойдет до конца. Но это не моя цель. Моя цель сейчас - написать метод. И я на нем фокусируюсь и проверяю только его поведение.

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

Т.е. сценарный тест проверяет взаимосвязь методов.
13. Сурикат 264 23.07.19 11:01 Сейчас в теме
(8)
Я именно это и пытался сделать, видимо не получилось =(

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

Сценарное тестирование - я проверяю как построен дом, а модульное тестирование - я проверяю кирпичи. Иногда очень здорово знать, что кирпичи, из которых мы строим дом, отличного качества =) И не только здорово, но и удобно, т.к. обратную связь можно получить быстрее.

Наличие модульных тестов, не гарантирует работоспособности процесса. И если наша задача - проверить процесс, то вы абсолютно правы, модульный тест не самый лучший инструмент.
14. CheBurator 3399 23.07.19 14:19 Сейчас в теме
сколько пытаюсь представить - никак не получается.
вот допустим есть WMS. почти вся работа идет через RDP-доступ, обработки для ТСД.
как раз сценарное тестирование вроде бы подошло. Надо проверить ожидаемо ли отрабатывает куча нажатий по кнопочкам исполнителем (в т.ч. с учетом того, что с одного экрана по разным кнопочкам-горячим клавишам можно уйти на другие экраны где аналогично - очень быстро ветвится дерево возможностей). при этом то что видно на экране (в т.ч. и набор долступных горячих клавиш) определяется кучей настроечных параметров. как это все прогнать и оцениить правильно ли сценарий отработал или нет - я вообще не представляю. кроме как сидеть и наблюдать и тормозить если вижу проблему...
Или я неграмотный?
15. DmitryMironov 24.07.19 10:30 Сейчас в теме
(14)
Может стоить начать тестировать конкретные сценарии, а не просто сразу все возможные переходы и ветвления?
Например сценарий "Приемка товара", "Подбор товара", "Отгрузка товара" и т.д.
Каждый сценарий будет:
1. Показывать как ДОЛЖЕН работать функционал - можно также использовать как инструкцию для пользователей
2. Проверять что правильный путь сценария отрабатывает корректно
16. CheBurator 3399 24.07.19 11:52 Сейчас в теме
(15) ну да, только сам по себе сценарий "приемка товара" - достаточно развесистый. реально достаточно развесистый. и как быть? - дробить на суб-сценарии? где каждый субсценарий - это, например, одна включенная галочка в настройках? и как это вообще автоматом тестировать? автоматом включать-выключать настроечные галки и прогонять автоматом сценарий? как знать - правильно отработал сценарий или нет? вручную описывать сценарий (что само по себе уже является ручным прогоном этого сценария) для каждого набора настроечных параметров? ничего непонятно...
17. CheBurator 3399 24.07.19 11:54 Сейчас в теме
(15) сейчас по сути - выставляются конкретные настройки для какого-то одного варианта. и прогоняется сценарий вручную только для этих выставленных настроек.
18. Сурикат 264 24.07.19 12:49 Сейчас в теме
(17)
Выставляются конкретные настройки для какого-то одного варианта. и прогоняется сценарий вручную только для этих выставленных настроек


Автотест будет делать тоже самое. Только не в ручную проганяться будет, а автоматически. Можно распараллелить запуск тестов, запускать одновременно сразу несколько сценариев
19. CheBurator 3399 24.07.19 14:14 Сейчас в теме
(18) но по-любому, один раз сценарий надо прогнать вручную? и записать его? по всем возможным ветвлениям сценария?
20. Сурикат 264 24.07.19 14:54 Сейчас в теме
(19) Да, и даже не один.
Сценарий еще отладить нужно
21. CheBurator 3399 24.07.19 18:42 Сейчас в теме
(20) не, при тех ресурсах, которые есть - нереально
22. artbear 1156 29.07.19 17:34 Сейчас в теме
(19) Сергей, тебе уже несколько лет рассказывается и даже показывается, что тесты вполне реально можно сделать.
А ты все "нереально" :(

начни с малого - хотя бы один сценарий преврати в тест :)
24. CheBurator 3399 29.07.19 18:54 Сейчас в теме
(22) а сколько времени с нуля для неграмотного занимает развертывание "инфраструктуры" для работы с тестами-сценариями? (все на win-инфраструктуре)
25. Сурикат 264 29.07.19 21:33 Сейчас в теме
(24)
А вы уверены, что вам нужна инфраструктура?

По началу тесты можно и в ручную запускать. Запуск - 5 мин.
26. CheBurator 3399 29.07.19 22:34 Сейчас в теме
(25) и что - нажимания кнопочек и ввод значений будут сами по себе в тесте выполняться?
27. Сурикат 264 30.07.19 09:00 Сейчас в теме
(26)

Да, а вы чем-то другим в это время заниматься будете, более полезным
23. artbear 1156 29.07.19 17:35 Сейчас в теме
Все возможные ветвления не нужно проверять.
всегда компромисс и приоритезация тест.сценариев по разным критериям - бизнес-польза, частота срабатывания, легкость реализации и т.п.
Сурикат; +1 Ответить
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Бизнес-архитектор 1С, ведущий консультант
Санкт-Петербург
Полный день

Руководитель проектов 1С
Санкт-Петербург
Полный день

Программист 1С
Краснодар
зарплата от 80 000 руб. до 160 000 руб.
Полный день

Консультант 1 С
Краснодар
зарплата от 50 000 руб. до 150 000 руб.
Полный день

Консультант-методолог 1С
Краснодар
зарплата от 110 000 руб.
Полный день