вот кстати у меня вопрос, запуск Маском ракет - это Agile или нет?

проверяется это просто, продайте TDD маленькой компании которая понимает сколько кэша тратит на это :)

> Slava мой поинт если чего в том, что если продукт развивается, то TDD это тормоз TDD определяет дизайн кода. И если вы просто пишите тесты перед тем, как написать код - это не TDD, его стоит применять на определенных этапах разработки. Когда непонятен домен, когда непонятны подходы к разработке слабосвязанных компонент и т.д. Замедляет разработку все, что мы не знаем. Например, если пишем систему на Java и выносим какой-то микросервис, где лучше подходит Python, но в команде никто Python не знает - это замедляет разработку. Так же и с TDD, если команда не знает, где его применять, не имеет опыта с TDD, не понимает, где TDD, а где просто пишем Unit-тесты, это будет замедлять работу. Мы часто применяли TDD, чтобы сформировать подходящий дизайн в части системы. Затем тесты выбрасывали, поскольку свою работу они выполнили. Автоматическое тестирование делали уже через приемочные тесты, на более высоком уровне.

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

Контекст был в том, что перед нами стоял домен, который мы толком не понимали, как будет работать. Было много правил, которые вроде и описаны в пользовательских историях, но слишком много вопросов. Мы не понимали, как оно будет работать и, соответственно, как это спроектировать. Начали переносить требования в тесты, строить нужный домен внутри своей системы. Сформировав набор тестов, смогли сформулировать кейсы для бизнеса, которые требовали пояснений. Затем дополнили тесты и сформировали домен по ним, поддерживающий необходимые правила.

У меня получилось убедить команду в нашем ИП, которая пока работает в минус и разрабатывает платёжный агрегатор, стараться писать по TDD. Вы временные потери подсчитывали? Нас, например, это ускоряет. За счёт того что дефекты практически отсутствуют и быстро фиксятся. Вместо того что бы дебажить дефекты мы спокойно пилим новый функционал и полностью уверены в его качестве. К примеру, у нас был не стестдрайвен репозиторий транзакции, на разбор полётов у пары ушло ~40мин, на исправление дефекта ~2ч 40мин. Я уверен что лучше бы это время было бы потрачено на тестдрайвинг. Платить всё-равно пришлось.

#whois Всем привет) Евгений. Казань. Занимаюсь разработкой финтех продукта и аутсорс-разработкой на заказ. Активно практикую и стараюсь применять agile в работе:) Интересен обмен опытом и новые знакомства.

Много рассказов про TDD, а может кто-то есть кто работал по BDD? Интересует и позитивный, и негативный опыт.

Типа "как убедить, что все метрики д.быть сугубо индикативные, а мотивация по KPI - зло!@

не рассказывать про свои метрики подчиненным, делать вид что их вообще нет

По нашему опыту, BDD хорош тем, что дает больше понимания команде разработчиков о бизнесе. Разработчики больше начинают думать в терминах бизнес-кейсов, нежели каких-то техничеких модулей, классов и т.д.