Юнит-тесты в 1С: кому и зачем они нужны?
В 1С юнит-тесты до сих пор воспринимаются как диковинка, хотя на других стэках они давно вошли в культуру разработки.
Обычно про тесты говорят, что они помогают находить баги, и это правда, но я вижу их главную ценность в другом. Юнит-тест фиксирует, как именно должна работать функция и какого поведения мы от неё ждём. Когда через полгода этот код откроет другой разработчик, а то и я сама, упавший тест подскажет, что вот это менять нельзя, а зелёные тесты позволят спокойно заняться рефакторингом. Без юнит-тестов ответ на вопрос «как это должно работать» остаётся только в чьей-то голове или в старом ТЗ, от которого в процессе еще и молча отошли.
Мне кажется, что по культуре разработки 1С заметно отстаёт от большинства всемирно используемых языков. Максимум, что я встречала в тестировании, это автотесты на Vanessa Automation, и с регрессом они действительно помогают, хотя для них тоже сперва надо определиться с бизнес-процессами в системе. Но доводить баги до регресса – очевидно плохая практика, ведь к этому моменту ошибку исправлять дольше и дороже. Юнит-тест ловит ту же ошибку на уровне отдельной функции, ещё до того, как код сложится в целый сценарий.
Больше всего пользы я увидела при покрытии тестами легаси-кода. Чтобы написать тест, нужно знать ожидаемый результат, и на старом коде часто оказывается, что его никто не может назвать, потому что в ТЗ об этом ничего нет, а аналитик давно забыл, и код делает что-то своё, к чему все привыкли. Приходится выяснять, как должно быть на самом деле, и так находятся пробелы в бизнес-логике, о которых годами никто не подозревал.
Есть и неприятная сторона. Код, в котором запросы и обращения к форме перемешаны с логикой, нельзя сразу покрыть тестами, его приходится сначала разбирать на части, а это долго и не слишком весело, зато после этого он становится намного понятнее.
Для нового кода у меня теперь простое правило, что без теста я его не сдаю. А пишу я их на YaxUnit.
Отвечая на вопрос из заголовка: юнит-тесты нужны и бизнесу, и разработчикам. Бизнесу они дают предсказуемость: доработка в одном месте реже ломает то, что уже работало в другом, поэтому после релиза меньше срочных исправлений и меньше простоя у пользователей. К тому же согласованные правила остаются записанными в коде и не пропадают вместе с человеком, который их помнил, что сокращает затраты на передачу знаний. Разработчику тесты позволяют быстрее разбираться в коде, и менять даже чужой код без страха что-то сломать, а если сломалось, то сразу видно, где именно, и какое поведение ожидалось.
