Всем привет! Прогаю несколько лет, не только на 1С, но как-то всю жизнь попадал в отделы, где никто не использовал автотесты, а все тесты выполняли либо конечные пользователи, либо на одном месте был отдел тестировщиков, которые руками все тестировали.
Но я знал, про автотесты, но никогда не сталкивался с таким в живую и никак не могу понять, что это такое и как это работает?
Приведите, пожалуйста, реальные примеры, прям из практики, где применяются автоматизированные тесты? Я прям ну никак не могу себе это представить.
Предположим, делаю обмен с сайтом. Написал какой-то код, прогнал его. Далее возможны две ошибки, либо ошибка в коде, либо ошибка логическая. Ошибку логическую автотест никак не узнает, ему пофиг, что попало в поле цена - 100р или 999999999р. Ошибку в коде я сам увижу сразу же при запуске и полезу ее исправлять. Исправлю, запущу еще раз. Ну, или, пишу интерфейс для пользователя со 100 кнопками, каждая выполняет свою функцию. Опять тоже самое, либо ошибка логическая, либо ошибка кода.
Даже, если мне надо найти ошибку кода, пока я напишу бота, который прокликает 100 кнопок, я сам быстрее прокликаю их и проверю, появляется ли исключение или нет.
Приведите, пожалуйста, реальные примеры, желательно с вашей работы, которые вы использовали в последнее время, где вы используете автотесты и чем они лучше обычных тестов руками.
Спасибо.

Например каждый раз проверять:
1.не сломал ли твой новый овнокод старые механизмы.
2.проверять что при определенных входных условиях ты получаешь желаемый результат
и т.д.

"автотест никак не узнает, ему пофиг, что попало в поле цена - 100р или 999999999р" - значит ты не написал автотест, который покрывает этот кейс.

ну чисто теоретически можно комбинации RLS тестировать. Чтобы не делать одно и тоже под разными профилями

(0)Давно понятно, что лучше самих пользователей никто не потестирует. Причем именно в боевом рабочем режиме, только так)

Автотесты не призваны найти ошибку в коде, автотесты призваны зафиксировать состояние системы в какой то конкретной точке.
И при каждом изменении кода, тесты проверяют что внешнее поведение не изменилось, что может очень пригодится в случае если ты например затеял рефакторниг модуля, тест тебе сразу скажет изменилось ли поведение системы, без необходимости создания 100 документов.
Так же пригодятся если твоя доработка навернула смежный функционал который ты вообще не трогал.
В целом автотесты про : https://ru.wikipedia.org/wiki/Регрессионное_тестирование

Фактически выгоду ты получишь не сразу после написания тетста, а в дальнейшем.

Из реальной жизни, сейчас в рабочем режиме используются так называемые "дымные тесты", которые фактически открывают каждую формочку в конфе, и регистрируют формы которые не открылись.
Так же в прогоняется расширенная синтаксическая проверка модулей и сливает в отчёт все найденные ошибки, помогает отловить ошибки связанные с клиент серверным взаимодействием (очень актуально для ОФ, что бы ФЗ не падали напоровшись на твой кусок кода под толстого клиента), так же ловил всякие пустые процедуры и функции, невызываемые процедуры и функции и т.д и т.п.
Все эти танцы занимают порядка часа на прогон, ессесно руками этого никто не хочет делать, особенно после внесения каждого изменения, поэтому это делается каждую ночь в фоне, а с утра пробегаемся по отчётам тестирования и фиксим весь отловенный овнокод.
В целом это не панацея, но помогает отловить довольно много ошибок ещё до деплоя в проудктив.
В перспективе хотим начать писать тесты ко всей разработанной функциональности, но пока надо всех обучить инструментарию и некоей философии тестирования чтоли =)

(0) Делал тесты для автоматической проверки корректности перенесенных данных. Вручную перелопачивать большие массивы данных скучно, а иногда просто невозможно, а программная проверка занимала совсем немного времени.