TDD

[Igors]

Каждый раз поражаюсь тому бреду, что пишет Igors.

Когда мне было 20 - я удивлялся как глупы мои родители
Когда мне стало 30 - я удивился еще больше, когда они успели так поумнеть

[Racheengel]

Проблема только одна: разработчикам лень писать примитивный код. В юинт-тестах ничего интеллектуального нет. В некоторой степени рутинная работа.

Дело не только в лени - девелопер не должен тратить свое время на тестирование, т.к. он занят более важными вещами. Тестами же должен заниматься отдел QA. А это уже, увы, не бесплатно. Надо постоянно держать команду тестеров, которые к тому же будут понимать, что они делают. Мелким и средним фирмам это, увы, не по карману...

[Авварон]

Когда мне было 20 - я удивлялся как глупы мои родители
Когда мне стало 30 - я удивился еще больше, когда они успели так поумнеть

ну вот, опять

Дело не только в лени - девелопер не должен тратить свое время на тестирование, т.к. он занят более важными вещами. Тестами же должен заниматься отдел QA. А это уже, увы, не бесплатно. Надо постоянно держать команду тестеров, которые к тому же будут понимать, что они делают. Мелким и средним фирмам это, увы, не по карману...

Отдел тестирования должен тестировать черный ящик, а не доделывать за программиста его работу.
-Я тут отрефакторил класс, протестируйте пожалуйста
-Ок, через месяц, ща некогда.

[Tuxford]

Дело не только в лени - девелопер не должен тратить свое время на тестирование, т.к. он занят более важными вещами.

Компилируется значит работает. Тестировщики баг не нашли - прекрасно.

Тестами же должен заниматься отдел QA.

QA не должен заниматься юнит-тестированием.

А это уже, увы, не бесплатно. Надо постоянно держать команду тестеров, которые к тому же будут понимать, что они делают.

Рефакторить тоже не бесплатно. Давайте не будем делать рефакторинг. Работает, и хорошо.

Мелким и средним фирмам это, увы, не по карману...

Как определить большая/мелкая?

[Racheengel]

QA не должен заниматься юнит-тестированием.

Здрасьте приехали, а кто тогда? Еще один отдел с юнит тестерами создавать?

Рефакторить тоже не бесплатно. Давайте не будем делать рефакторинг. Работает, и хорошо.

Естественно, рефакторинг ради рефакторинга - это бред, если нет такой необходимости.

Как определить большая/мелкая?

Годовой оборот и количество сотрудников. Если в фирме человек 100 - то может она и может ТДД позволить, но если 20-30, из которых дай бог 10 девелоперов - то уж извините.

[Old]

Offtop'у

http://sintegrial.com - всякий хороший Qt софт

Подскажите, где здесь ссылка Download.

[_Bers]

Проблема только одна: разработчикам лень писать примитивный код. В юинт-тестах ничего интеллектуального нет. В некоторой степени рутинная работа.

Дело не только в лени - девелопер не должен тратить свое время на тестирование, т.к. он занят более важными вещами. Тестами же должен заниматься отдел QA. А это уже, увы, не бесплатно. Надо постоянно держать команду тестеров, которые к тому же будут понимать, что они делают. Мелким и средним фирмам это, увы, не по карману...

это не просто бред - это шторки в мозгах.

могу объяснить.

[m_ax]

Тож немного поофтоплю)

Подскажите, где здесь ссылка Download.  

А вы уверены, что она там вообще есть?
Результат  переводчика:

[Racheengel]

Захавали китайцы сайт, по ходу... жалко,хороший был...

[Tuxford]

QA не должен заниматься юнит-тестированием.

Здрасьте приехали, а кто тогда? Еще один отдел с юнит тестерами создавать?

QA должны тестировать конечный продукт, а не код. Тестировать, дебажить код, это дело девелоперов а не тестироващиков.

Рефакторить тоже не бесплатно. Давайте не будем делать рефакторинг. Работает, и хорошо.

Естественно, рефакторинг ради рефакторинга - это бред, если нет такой необходимости.

Берем такую ситуацию. Надо добавить новую фичу. Грубо говоря была поддержка протокола Х, теперь надо еще Y, а через некоторое время еще Z. Есть несколько вариантов. Потратить 20 условных человеко-часов (далее учч) на доработку фичи 1, потом надо будет еще потратить 30 учч на доработку второй фичи. Есть третий вариант. Отрефакторить код, потратив на это 30 учч, потом потратить по 5 учч на обе фичи. В итоге имеем, что первую фичу будем делать 35 учч, вторую всего 5. Экономия 15 учч. Согласны?
Здесь по моему все очевидно.
Можно взять другую ситуацию. Есть некий индусский код. Знаете что это такое? Потенциально возможны проблемы. Ну скажем юзер запустить на какой то медленной тачке и тогда начнутся проблемы с многопоточностью. Здесь это как можно рассценивать?

Как определить большая/мелкая?

Годовой оборот и количество сотрудников. Если в фирме человек 100 - то может она и может ТДД позволить, но если 20-30, из которых дай бог 10 девелоперов - то уж извините.

Тогда мне какие-то странные конторы попадались на пути. Тим из 3х человек юзал ТДД по полной Не говоря уже 10. В первом случае в конторе всего было 9 людей.

[Igors]

Есть третий вариант. Отрефакторить код, потратив на это 30 учч, потом потратить по 5 учч на обе фичи. В итоге имеем, что первую фичу будем делать 35 учч, вторую всего 5. Экономия 15 учч. Согласны?
Здесь по моему все очевидно.

Вы переоцениваете собственный опыт (впрочем это свойственно всем). Да, случай что Вы рассказали вполне возможен/реален. Но это совсем не значит что рефакторинг всегда выглядит так. Напр я трачу гораздо больше "учч" чтобы хотя бы собрать тот или иной класс из мегатонны процедурного кода что я имею. Вот один класс собирал неделю, потом ловил новые баги (обсуждение на этом форуме).

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

[Tuxford]

Есть третий вариант. Отрефакторить код, потратив на это 30 учч, потом потратить по 5 учч на обе фичи. В итоге имеем, что первую фичу будем делать 35 учч, вторую всего 5. Экономия 15 учч. Согласны?
Здесь по моему все очевидно.

Вы переоцениваете собственный опыт (впрочем это свойственно всем). Да, случай что Вы рассказали вполне возможен/реален. Но это совсем не значит что рефакторинг всегда выглядит так. Напр я трачу гораздо больше "учч" чтобы хотя бы собрать тот или иной класс из мегатонны процедурного кода что я имею. Вот один класс собирал неделю, потом ловил новые баги (обсуждение на этом форуме).

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

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

Дело в том что я вашей задачи не знаю. И мне трудно что-то конкретно сказать. Но я уверен, найти можно. Что тут сказать, если в эмбеддед с использованием osgi где-то 40% удалось покрыть юнит-тестами.

[Igors]

Дело в том что я вашей задачи не знаю. И мне трудно что-то конкретно сказать.

Так это нормально что не знаете. Девелопмент (последнее "D" в TDD) на то и девелопмент чтобы создавать новое. А то выходит что Вы делаете глобальные выводы на основании круга задач которые Вы хорошо изучили и не раз писали подобные. Так можно доказать любые концепции, в том числе и противоположные. А вот у Вас новая задача, покажите как Вы будете ее разрабатывать (а не "по готовому") методом тестирования. Заметим что когда та же задача приводилась для демонстрации boost::spirit - никто хвостик не поджимал и на "не знаю" не ссылался  

Но я уверен, найти можно.

Ну так "прошу", а то пока хз что. Типа "проверить с пустым или калечным файлом"... И что, в чем смысл? Как это потом мне поможет в разработке? Типа "лепи абы какие тесты, так в вумной книжке напысано"  

[Tuxford]

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

[QuAzI]

Вот один класс собирал неделю, потом ловил новые баги (обсуждение на этом форуме).

Мне одному кажется, что тут изначально, без всяких тестов, что-то не так?
Дайте, пожалуйста, ссылку на обсуждение, я почитаю на досуге, вдруг пойму высший замысел