Плюсую, обычно ведь есть ТЗшки, а если функциональные требования постоянно меняются.. то даже не знаю что делать: наверно стоит начинать с процессов :)
К чему это я написал, это к тому вы написали не корректное ироничное замечание, потому что часы -- это предмет и их функциональные требования для часов -- это показывать корректное время в любой момент времени
В статье идет речь о методологии, у которой есть границы применимости
Мне кажется вы неправы уже с начала статьи: "TDD - это неправильная практика. Она всегда была неправильной. Она неправильна по определению. Ее главная заслуга - поощрение тестирования, но на этом все и заканчивается."
TDD -- это концепция с своей границей применимости. Писать на все TDD не имеет смысла если у вас постоянно меняются функциональные требования.
TDD больше всего подходит для проектов с ясными функциональными требованиями, в идеале с Техническими Заданиями. Не рационально использовать TDD на участке где функциональные требования меняются каждый день.
Также не рационально пихать TDD на среды где затруднено писать тесты: это будет доставлять больше неудобства чем business value в виде качества продукта. Тем более если нет автоматизации тестирования
Тем более если код меняется очень часто, то тесты не становятся такими легкими в поддержании и вместо обеспечения качества они начинают мешать разработке.
Лучше всего использовать TDD на проектах с ясными функциональными требованиями (такое редко, но все же случается), с высокой степенью автоматизации и в основном на core domain часть, которая зафиксирована и меняется крайне редко: процессинги, шедулеры etc
Поэтому утверждать "TDD - это неправильная практика" -- это популизм, оправдывающий плохие практики и некомпетентность техлидов
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Плюсую, обычно ведь есть ТЗшки, а если функциональные требования постоянно меняются.. то даже не знаю что делать: наверно стоит начинать с процессов :)
У меня тоже есть:
- Официант, яйца
- Вареные или жареные?
- Почесать
(с) Стетхем
К чему это я написал, это к тому вы написали не корректное ироничное замечание, потому что часы -- это предмет и их функциональные требования для часов -- это показывать корректное время в любой момент времени
В статье идет речь о методологии, у которой есть границы применимости
Сравнивать теплое с мягким неправильно ж-)
Мне кажется вы неправы уже с начала статьи: "TDD - это неправильная практика. Она всегда была неправильной. Она неправильна по определению. Ее главная заслуга - поощрение тестирования, но на этом все и заканчивается."
TDD -- это концепция с своей границей применимости. Писать на все TDD не имеет смысла если у вас постоянно меняются функциональные требования.
TDD больше всего подходит для проектов с ясными функциональными требованиями, в идеале с Техническими Заданиями. Не рационально использовать TDD на участке где функциональные требования меняются каждый день.
Также не рационально пихать TDD на среды где затруднено писать тесты: это будет доставлять больше неудобства чем business value в виде качества продукта. Тем более если нет автоматизации тестирования
Тем более если код меняется очень часто, то тесты не становятся такими легкими в поддержании и вместо обеспечения качества они начинают мешать разработке.
Лучше всего использовать TDD на проектах с ясными функциональными требованиями (такое редко, но все же случается), с высокой степенью автоматизации и в основном на core domain часть, которая зафиксирована и меняется крайне редко: процессинги, шедулеры etc
Поэтому утверждать "TDD - это неправильная практика" -- это популизм, оправдывающий плохие практики и некомпетентность техлидов