А еще Ванесса-АДД недавно научился прогонять тесты из расширений.
И давно умеет прогонять тесты из конфигураций
И даже есть смерженный ПР по запуску тестов откуда угодно - модуль объекта, менеджер объекта метаданных и т.п.
6.
NikitaIvanchenko
12202.02.23 15:24 Сейчас в теме
(5)
Спасибо за отзыв. Если поднимать тему про аллюр, то нужно рассказать и про него. Что это, как поднять. Получается очень обширно для одной статьи. И дымовые тесты это все же не совсем про юниты. Я статью позиционирую как точка входа для тех, кто совсем не знаком с тестированием. А вот когда человек войдет в тему, уже дальше сможет пойти и открыть для себя аллюр, ci\cd и прочие радости.
20.
NikitaIvanchenko
12206.02.23 14:25 Сейчас в теме
(19)
Все же это в большей степени сценарное тестирование. И это немного другой этап разработки.
Наличие любых тестов хорошо, и сценарного, и модульного. А отсутствие тестов - плохо. Но мое мнение таково, что именно модульное максимально ближе к сознанию разработчика. Ну и по сценарному тестированию статей и видосиков много.
22.
NikitaIvanchenko
12207.02.23 09:43 Сейчас в теме
(21)
Добрый день.
Наверно скажу ужасную вещь, на текущий момент мы отказались от замеров покрытия, и дымовых тестов. Но это не значит, что это не нужно и не полезно. Просто сейчас перестраиваем процессы. Хотим что бы дымовые работали не по всем формам, а только там где хотим и где это нужно. По замерам, пытаемся пойти не за абсолютными цифрами. А за конкретной помощью разработчику. Условно - какая часть в новом коде(в пул реквесте) не покрыта тестом. Возможно какие либо ветвления по условиям пропущены и т.д. Повторюсь, я преследую цель, что бы это ощущалось как естественный процесс, в котором инструменты помогают, а не тормозят бюрократией =)
А пока этот процесс в разработке, у нас одно простое правило. Новый код покрывается тестами, методы проверяются на ожидаемое поведение. Если трогаем "старый" код, тоже пишем тест. Но только на те места, которые "потрогали". Без фанатизма.
Как на практике выполняется тестирование, когда нужно протестировать большое количество методов одного объекта? Для каждого тестируемого метода добавляется ключевое слово Экспорт или есть еще какой-то хак?
Хочется вносить минимум изменений в тестируемый код и не делать все методы объекта / формы экспортными... Или это неизбежная плата за наличие тестов?
Напрашивается какой-то один экспортный метод с командой Выполнить(ИмяМетода_Параметры). Как в приведенном примере в статье: Процедура ВыполнитьСерверныйТестФормы(ИмяТеста, ТестируемаяФорма) Экспорт. Только не в модуле обработки, а в самом тестируемом объекте...
24.
NikitaIvanchenko
12209.02.23 15:36 Сейчас в теме
(23)
Да, платить придется в любом случае. Серебряной пули нет, или я не знаю. Либо делать экспорт, либо как вы предложили просверлить универсальную процедуру. Или сделать расширение, в котором будет экспортная обертка над не экспортными методами. Как мне кажется, если тестируются методы основной конфигурации, то самый удобный вариант - через расширение. Но тут каждый сам выбирает, что ему удобней.
Храню плагины в отдельном каталоге репозитория. Хочу иметь удобный способ подключать их как при локальных прогонах, так и в CI (без копирования в папку `Каталог_Vanessa_add/plugins`).
У раннера появилась возможность подключать плагины из произвольного каталога? Если нет, то как вы прокидываете свои плагины в CI?
28.
NikitaIvanchenko
12221.02.23 16:50 Сейчас в теме
(27)
Vanessa Automation - Мощный набор инструментов для сценарного тестирования. В котором помимо тестов можно генерить всевозможные видео-инструкции с голосовой озвучкой.
Vanessa Add помимо модульных тестов, о которых эта статья, тоже позволяет разрабатывать сценарные тесты. Для обоих инструментов по сценарным тестам много статей, и видосиков на ютубе. Говорить какой из них лучше, я на себя такой ответственности брать не буду. Лучше попробовать оба, и самому определиться, что удобнее.