Comments 9
Простите, но вы только что узнали про тесты и решили написать статью на хабр? С чего вы решили, что они не популярны в СНГ? И как же по-вашему работают IT-компании и пишут продакшен-код?
я из клиентской мобильной разработки. у нас часто идут споры об их необходимости. У нас большие продакшен компании далеко не все пишут код с тестами, или пишут их для видимости
Часто в том же бэке тесты — необходимость. К сожалению, в других платформах пока еще слабая культура
>К сожалению, в других платформах пока еще слабая культура
Работаю в крупном федеральном ритейлере, тесты есть и для бэка (юнит + интеграционные) и UI тесты (JavaScript, React).
Вот за мобилку не знаю правда
Вот есть такой грешок на постсоветском, есть-есть… сами себя же потом выгоняют в итоге на ночные бдения «аврал, дедлайн, почему всё сдохло???», а из всех инструментов поиска — дебаггером гонять данные от и до и пытаться «пальцем по экрану» понять, что не так. А где же возможность тестирования? «Ой, мы постоянно так заняты, на неё времени нет».
Я свой персональный проект сразу порезал на бинарные модули и при любой доработке любого модуля старый и новый запускаю в параллель на наборе данных, предусматривающий мыслимые и немыслимые косяки, и если оба выдают бинарно идентичный результат — перехожу к тестированию новых фич. А потом — снова на старых, чтобы убедиться, что там ничего не повредилось в новом режиме, включая настройки.
Но у меня всё довольно-таки самобытно-велосипедно организовано, я довольно далёк от устоявшихся в IT корпоративных подходов, так что мой основной девиз — паранойя. Сначала прога состоит из бага — её нет, значит, в ней неправильно всё. Потом число багов становится конечным, и начинается охота. Разбить лес на квадраты и прочёсывать граблями, и если где-то хотя бы один шорох листа не соответствует теоретическому ожиданию, пусть даже всё работает и результат верный — баг там, его надо ловить. Исключений не бывает.
Но я специальных тестов не пишу — у меня такой вот инкрементальный подход, то есть сначала «не сломать старое», а для этого самый главный тест — тест «об уже имеющийся проверенный модуль». Наверное, такое тестирование можно назвать в некоторой степени автоматизированным.
Не везде их пишут)
Простите, но у вас, в корне неверная система оценки полезности тестов (да и вообще любой технологии).
Полезность любой практики для проекта должна оцениваться следующим образом.
Насколько практика или технология увеличивает прибыль клиента приложения? Клиент будет больше получать прибыли от приложения после внедрения tdd? Нет. С чего бы?
То, что вам, как исполнителю, будет удобно и приятнее работать, не имеет значения. Проект не для вашего удовольствия оплачивается.
Код будет качественнее? Нет. Это враньё. Tdd не приводит к увеличению качества работы. Качество кода - это соответствие работы приложения требованиям заказчика. Точное соответствие функционала кода прописанным в проекте алгоритмам. Tdd обеспечивает точное соответствие функционала приложения прописанным в проекте алгоритмам? Нет. Для многих откровением будет, что юнит тесты обеспечивают соответствие функционала только самим юнит-тестам. Сами юнит-тесты могут не соответствовать проекту. Кто будет тестировать юнит-тесты? Чтобы функционал соответствовал требованиям заказчика, нужно следующее: проект, отдел тестирования, отдельный от разрабов и аналитиков (у корейцев тестирование проводит вообще сторонняя контора, слышал). И самое главное - репрессивная система, способная карать исполнителей за несоответствие функционала проекту.
unit-тестирование здорового человека ч.1