с терминологией еще не очень силен. но скорее, сценарные.

тесты не писал.

рекомендую цикл статей Владимира Литвиненко на инфостарте, должен подойти и для va

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

спасибо!

Александр, спасибо! Будем потихоньку разбираться.

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

для юнитов код нетестопригодный бывает в наличии. и чтобы порефакторить приходится начинать с поведенческих, чтобы накрыть это всё богатство)

Когда я погрузился в TDD, я понял что просто код писал неправильно. :)

Вчера в АДД увидел стандартный набор дымовых тестов на проверку открытия форм. Прям восторг )

Я тоже с этим столкнулся.... и еще думаю столкнусь

Когда пишешь код с мыслью: а как я могу написанное проверить - начинаешь писать по другому.
Я тут под юнит тесты свой код так перефакторил, что слезы наворачиваются. :)

👍 имхо это самый крутой выхлоп от TDD.

Слезы чего? :)

Просветления

"одной рукой набираю код, другой слезы счастья утираю"

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

Не плохо бы еще просто архитектурные паттерны изучить тогда уж было)

Разделение кода на функции должно быть осмысленным. Странно требовать от разработчика функцию в 15 значимых строк, если эта функция никогда не вызывается в двух местах.

VA умеет такое:  экспортный сценарий со множеством параметров
при использовании сценарии как шага можно передать таблицу (в фича-файле),
колонки которой - это имена параметров экспортного сценария
в строках, соответственно, находятся значения параметров
экспортный сценарий выполняется столько раз, сколько строк в таблице
?

Я не большой специалист по ВА. Но желаемое поведение на мой взгляд противоречит концепции ВА.
У меня есть похожая задача, когда необходимо одну мега функцию протестировать в разных режимах.
По сути дела каждая строка таблицы это отдельный сценарий, который хочется видеть отдельной строкой в ВА. Чтобы ВА сама размножила сценарии.
Я бы сделал автогенерацию фичи со сценариями по таблице значений, а в ВА подсовывал бы автогенереную фичу. Так будет проще и понятнее.