Всегда проверяй свой код!

iSmokeJC, в смысле? вроде все выложил. Или ты о чем?


Звук да, просит правок, но пока как есть с древним микрофоном.(

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

MrOnlineCoder, ситуация к сожалению частая и знакомая до боли. Гарантированных рецептов нет, могу поделиться опытом как это можно решать (есть положительный опыт). Начинать в любом случае с чего то надо:
1) договариваемся с командой, что пишем юниты на новые методы, и при исправлении багов на поправленные методы. Таким образом перед командой не стоит неосуществимая задача покрыть все тестами, но с другой стороны юниты появляются и их число растет. Вторая польза в том, что начинаем писать юниты на критичные места (покрывая тестами при багах)
2) узнаем у ручников-тестировщиков, аналитиков, разрабов самые критичные и проблемные места (это не всегда одно и то же) и прикидываем самый простой способ тестировать их. Это я к тому что до последнего не трогаем е2е тесты, типа УИ-тестов на селениуме для веба. Ибо медленные, тяжелые, не особо надежные. Больше смотрим на тесты апи и интеграционные типа сверки с бд, валидации данных и т.п. Тут уже нужен или отдельный автоматизатор или чел в команде, которые сваяет тесты. Это уже не юниты, но и они тут могут быть, если скажем мы убедим лида написать таски для тестов только самого критичного
3) самое тяжелое, сложное, трудно повторяемое тестируем уже на УИ, желательно чтобы таких тестов было немного. В общем если у нас нет вариантов протестировать какое то поведение, фичу уровнями ниже.

4) тесты обязательно ставим частью сборки(!). Этот шаг почему то часто забывают и они где то там отдельно гоняются. Не прогнав юниты код не мержится в ветки. Не прогнав интеграшки+апи не деплоим и т.д. То есть упавшие тесты должны фейлить сборку и деплой, а не бежать где то там в отдельном окружении. Это нам не только дает гарантии кое-какие (поначалу весьма призрачные) но и приучает разрабов смотреть за тестами, внимательно к ним относиться, понимать зачем они.

Естественно тут есть много НО, много нюансов, типа когда в продакшн, сколько у нас ручников, есть ли спецификации на продукт, сколько у нас вообще ресурсов и времени, насколько команда понимает тестирование и готова идти навстречу. До сих пор живы люди, которые считают что тесты это лишь трата времени и "вон же есть тестировщики, пусть себе смотрят".

Короче, если тестирование в проект сразу не закладывалось (обычное дело) и разработчики тесты не писали, то все будет грустно, тяжело и не быстро.

Сумбурно наверное написал) Но тут кратко наверное не напишешь.

XLAT, так я ж для новичков, они пока не знают что такое юниты и либ типа юниттеста или питеста в глаза не видели. Потому с ассертов начал, как с простого примера и формирования привычки к тестам.

чуть ли не автоматом выведут вас на правильную дорогу.

Абсолютно верно. Если команда начинает писать тесты, быстро обнаруживается, что для простоты их написания и код должен быть написан определенным образом, начинают изначально планировать все так, чтобы легче было проверять. Так что с вами полностью согласен -тесты это очень пользительная вещь.

уже закрыл его для себя