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

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

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

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

Комментарии
Избранное Подписка Сортировка: Древо
1. sapervodichka 1751 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 1751 22.07.19 15:36 Сейчас в теме
(2) спасибо))) главное, что она есть
4. artbear 1157 22.07.19 15:40 Сейчас в теме
(1) А эта Ваш набор обработок не является ли набором обработок из раздела ERP ?

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

или я ошибаюсь?
5. artbear 1157 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 1157 22.07.19 19:28 Сейчас в теме
(8) В рамках 1С "настоящие" юнит-тесты слабо возможны, т.к. наши тесты не отделимы от самой конфигурации 1С, платформы, СУБД и т.п.

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

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

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

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

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

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


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

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

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

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

Вакансии

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

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

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

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