Russian Qt Forum

Добрый день

Вот опять встретил человека который, как я понял, юзает TDD вовсю. Никогда не понимал в чем там кайф. Вику откроешь - ну такая фигня, прости господи. Сначала пишем - тест не проходит, потом еще пишем - проходит. И шо? Не говоря уже о том что выделить кусок для теста часто непросто. Наверное я чего-то не понял, поясните.

Спасибо

А вот тут вы сами признались, что не умеете писать код.

Igors,  советую просто почитать книгу по TDD (Кент Бек).

::)

Как фан ТДД скажу какой бенефит.
1. Существенно легче ловить баги.
2. ТДД заставляет писать более гибкий код.
3. В сулачае рефакторинга вещь просто незаменимая.
4. Хотя кода больше приблизительно в 2-3 раза, но в результате, когда проект рарастается, время разработки уменьшается.

Ну хорошо, читаю (аттач). Быстро понял что вначале надо "накидать" (часто с заглушками). а потом уж углубляться и разрисовывать каждый класс в деталях. Сам так часто делаю. Но причем здесь какие-то "тесты", откуда они берутся, как создаются? Отдельный проект что ли делать - так это в большинстве случаев нереально.   

Все в пределах одного проекта. Тесты выносятся в отдельную иерархию подкаталогов (один из подходов). Посмотри Креатор, например.

Я так делаю:
Есть отдельные классы для чтения, записи разных форматов файлов. Между ними есть связь в виде абстрактных классов.
Для каждого типа файла создаю тест на чтение и запись.

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

У меня только 1 проект с использованием тдд. Но я вижу для себя большой плюс в том, что я могу поменять какую-то функцию в абстрактном классе и быть спокойным, что у меня ничего не порушится в наследниках.
Я вот, не представляю, как бы можно было разрабатывать Qt без тестов. Внесли какие-то изменения в QObject и как дальше быть? Есть гарантии, что библиотека функционирует полностью? :)

Это называется Regression Tests, немного другая штука. Регрессионные тесты очень важны, естественно. Все уже было придумано до появления бренда TDD :)

Я использую др IDE, но и там прицепить файл (или суб-проект) не проблема. Но что писать в файле теста?  ???

Напр я знаю что в файле записана модель кубика. Значит прочитав его и визуализировав я должен увидеть кубик. Так и я делаю, но причем здесь  TDD?

Как говорил мой препод
Если ошибиться в QObject - полезет из всех щелей

TDD звучит вкусно, делать его нудно и зачастую неудобно. По крайней мере я не видел ещё IDE, которые позволяли бы делать нормальные TDD без многократного копирования уже готового кода в отдельные проекты.

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

Идея хорошая, а вот реализация по TDD замедляет проект раз в 10, если не больше. Вроде бы даёт надёжность, а с другой стороны изменение пары строк в основном проекте тянет за собой изменение всех тестов связанных с этим участком, и иногда отнюдь не на пару строк.

Хотя если писать программу по четкому ТЗ, с полной моделью(архитектурой) кода, прошедшему многократные проверки всеми специалистами - тогда да, тогда TDD даст то, ради чего создан :)

PS на мой вид это часть Идеальной Программы, именно с больших букв.

Ну, собственно, ради этого ТДД и был придуман - чтобы искусственно завысить себестоимость продукта. Веселые селл-агенты с серьезными лицами распространяют ТДД-литературу, ТДД-методологию, проводят ТДД-семинары и тренинги :) Двигают тренд, так сказать. Соответственно косят денюжку. Такой подход не нов - убедить, что это нужно именно ВАМ и именно СЕЙЧАС, а потом подсадить на крючок саппорта. Естественно, внедрять ТДД на фирме или нет - решают не разработчики, а верхний менеджмент. Кто-то за откат, кого-то охмурили "надежным кодом на выходе". Соответственно тратятся ресурсы в Х раз больше, чем обычное регресионное тестирование без ТДД. Это бизнес, ничего личного :)

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

Вы тут несете какую-то хуйню. Покрытие тестами проверяется анализаторами, их кучи. Из практики - у нас те, кто не писал тесты (не надо, кстати, путать ТДД и написание тестов в принципе) ловили баги от отдела тестирования, исправляли, ловили баги от отдела тестирования, и так бесконено. Те, кто сразу писал тесты, брали и переходили к другой задаче, пока первые не могли закончить.

Т.е. ситуаций что тест работал неправильно не было?

PS тут собственно и ждем мнения человека их использующего.

Такие реплики только роняют Вас ниже плинтуса, убедительность же их нулевая  :)

Какими "анализаторами"? Из какой "кучи"? Хз ???

Ага, еще и отдел тестирования (видать немало народу пригрелось). О том что тесты нужны я и сам знаю. Но тесты сами по себе - не TDD. Там утверждается о "разработке на основе тестов", о "движении вперед маленькими, но надежными(!) шагами". Я. право, не представляю как это на практике.

Ну хорошо, вот задача которую здесь делали многие - чтение obj файла. Это очень простой формат, полагаем что читаем только вертексы и фейсы, а материалы и др навороты игнорируем. Написать это час с нуля по описанию (https://ru.wikipedia.org/wiki/Obj). И что? Как это должно быть "с методом TDD"? Как двигаться "тест за тестом"?  Если такой пример слишком сложен - приведите свой

Ну работает неправильно, берете и исправляете тест. Это очень редкая ситуация - как раз на этапе стыковки теста и кода вы вычищаете баги и там и там. Зачем для этого нужны тесты на тесты? Люди типа вас, наверное, и придумали autotools - генератор для генератора для генератора. А, ну и тесты должны быть максимально простыми в начале. Я хз сколько неинициализированных переменных я выявил банальным тестом на дефолтвалуе/геттер/сеттер.

Ну я не знаю как еще реагировать на людей, делающих заявы из серии "я в школе не учился, мне это в жизни ни разу не пригодилось"

Вроде бы, мы CppCheck юзали. Там было покрытие построчное/процентное.

Лол, то есть у вас даже отдела тестирования нет? Какое счастье, что люди типа вас не работают на биржах/не пишут ПО для АЭС/самолетов.
Ну вы АПИ набросайте для начала. Навскидку - скормить пустой файл, невалидный файл, файл только с вертексами, только с фейсами, с тем и тем, файл с наворотоами.

Тогда почему очень много опенсорс проектор использую ТДД? Не находите противоречия. 
Если на то пошло, то много времени тратится в начале. Потом меньше. Я уже писал почему.

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

К тому же я не знаю ни одного известного проекта, например, который бы был полностью некоммерческим и использовал каноничный ТДД. Просто ТДД по определению требует бюджет, который может значительно превышать стоимость разработки продукта.

Ну как-то не слышно уверенности в голосе :) Никак не пойму что же я должен "тестить"-то? Ну создал пустой файл (может лучше только с комментами?) И что? Какую часть ридера я должен иметь на этот момент разработки? (это я как-то пытаюсь связать концы с концами)

Что-то мне это начинает напоминать язык где все время приводится один пример, и там выходит что Мухтар... собака! Ну и типа "предикаты". Здесь тоже, тесты-тесты, а понту/толку ???

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

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

1. ТДД не может быть каноническим. В каждом случае что-то нужно упустить, что-то добавить
2. Что такое полностью некомерческий продукт?
3. По поводу бюджета, я уже писал, что это не увеличивает, кроме случаев когда все изчисляется в строках кода и пр. извращенными метриками.

Я не прошу писать тонны кода - просто "на пальцах", простом примере объяснить что к чему. Что это за метод если, оказывается, это "слишком сложно сделать"? И я никого не заставляю меня учить - на нет и суда нет  :)

Edit: вспомнился случай/задача. Есть треугольник ABC. Известны длины всех его сторон (a, b, c) и координаты точек A(x1, y1) и B(x2, y2). Найти координаты С(x. y). Человек привел такое решение
Да, действительно, это сложно на форуме (читай "слишком много кода"  :)), но это и столь же неэффективно. А ведь ничего сложного в задачке не было и объяснить как решать легко.

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

Я не заставляю Вас что-то вообще для меня делать :) Книгу читали - уже хорошо  :). Я тоже много чего читаю (пролистываю) но пользоваться всем что прочитал не спешу. Хотелось бы услышать мнение кто юзает на практике - но тут (пока) дальше общих слов дело не идет

Доводов было предостаточно, если Вы их не видите, то что можно поделать?

Хорошо, посчитаем просто. Пусть Xр - стоимость разработки (без ТДД), плюс Хт - стоимость тестирования по окончанию разработки, плюс Хс - стоимость саппорта. Тогда себестоимость проекта будет считаться как X = Xp+Xт+Xc.

С применением ТДД необходимо добавить Xтдд - время разработки и поддержки тестов, плюc Хтддс - время внедрения и поддержки ТДД-технологии (сюда идут как семинары, обучения, так и издержки на администрирование системы тестов). Имеем X = Xp+Xт+Xc+Xтдд+Хтддс. А как известно, Xтдд+Хтддс может быть >= Xp.

Извините, ни быстрее, ни дешевле не получается...


Как и все вокруг.


Имеется в виду проект, который делается на чистом энтузиазме и не ставит цели прямо или косвенно приносить прибыль. Конечно, тут плюс в том, что и время на проект неограничено, и тогда можно развернуться в ТДД по полной, написав тесты на каждый метод каждого класса. Но тогда есть риск, что проект никогда не выйдет из стадии тестирования.


Бюджет часто зависит от сроков исполнения. ТДД позволяет волшебным образом увеличить и то, и другое :) За это его и любят.

Представь, нет отдела тестирования.
И да, писал по для средств защиты гос. границ/ АЭС нашей родины :) И могу гарантировать, что в других смежных отделах, где средства защиты разрабатывались, тоже нет отдела тестирования...
Трудно заиметь отдел тестирования, если ведущий инженер-программист получает 25к. Собственно это и было причиной моего ухода (я не был ведущим, я получал меньше).
 
Использующих ТДД просят "просто" рассказать о преимуществах и минусах на примере. Пока что видно нежелание даже поднимать эту тему.
Ссылаться на учебники можно и нужно, но не по такому вопросу.
От вас просят взять свои знания, сплетённые с опытом применения ТДД и сделать выжимку этих знаний, а не ссылаться на книги с чистой теорией.

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

PS я вот к примеру не смог ответить на вопрос - как сделать тест, имитирующий реакцию пользователя (щелчок кнопок, глобальные клавиши, открытие нескольких окон, ввод данных, запись данных).

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

То ли ТДД рекомендует разбить это на простые действия, но тогда смысл тестов исчезает - проверяется не комплекс, а отдельные части.

PPS если ты чем то пользуешься и не понимаешь принципов на которых это работает и чем полезно - значит ты обезъяна с гранатой, разбивающая кокос.

PPPS заканчивая поток сознания -
Вы предлаете прочитать книгу - многопоточное программирование я осваивал по книгам, в результате были сотни неудачных попыток и в результате одна работающая комбинация(со скрытой гонкой потоков, как оказалось потом).
А мы просим выдержку, опыт + теория - а вот общение с специалистом (2 часа) + листок бумажки пояснил мне всё.

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

Я может сильно чью то уверенность в безопасности АЭС/самолетов сейчас подорву, но на самом деле в наших предприятиях в подавляющем случае таких не то чтобы подразделений, а и должностей нет. Я, по крайней мере, ни в одном из многих известных мне лично организаций весьма схожего профиля тестировщика (в современном понимании этого слова) не видел. И уж о TTD там точно никто не задумывался. Отдел технического контроля, да есть. Но у него СОВСЕМ другие функции.

Что и говорить, если должности "программист" нет... Есть инженер, старший инженер и техник :D

Не, ну объявить "фигня, понты" всегда успеется. Я пытаюсь настроиться позитивно и понять светлые стороны
(классика советского кино)

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

Также меня смущает как отрабатываются более крупные, не побоюсь этого слова, "архитектурные" изменения. Напр то же чтение obj файла. Поначалу решил хранить вертексы и фейсы просто в контейнерах. Ну ладно, сделал.  Потом выяснилось что так не очень хорошо, напр для рисования с OpenGL. Переделал, теперь вместо контейнеров класс который знает что делать с геометрией. А как же с массой написанных тестов  ??? Шо, опять все по новой?  :'(

Насколько я понял, это к TDD отношения не имеет, это "просто тест". А что без тестирования и отладки ничего не живет - то ясно

Ну это значит, что вы не продумали использование. Очевидно, что должен быть класс с методами load/save(?) возвращающими как-то ошибку. И должен быть файл с тестом на этот класс. Если же у вас в левом месте ф-ия, к-ая читает данные в пачку контейнеров, принимая их по ссылке - это кривая "архитектура" by definition.
То, что АПИ класса меняется - это нормально. И тесты вам помогут его поменять, а не помешают. Добавили новое АПИ - исправили тесты, убедились, что работает, перешли на новое АПИ в коде, удалили старый. Можно даже не запускать приложение - 90% что регрессий вы не внесли. В случае отстутствия теста вам придется разбираться где вы там что забыли инициализировать по портянкам коллстеков в 60 вызовов.

Мне кажется это решение (пачка контейнеров) не заслуживает осуждения. Во всяком случае именно так делают во многих open sources. С год назад тут показывалось как круто это сделать на boost::spirit - и тоже была бааальшая пачка :)  Достоинство obj текстовика - что вот так "тыц и готово" проходит. Конечно капитальным такое решение не назовешь, но часто большего и не требуется.

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

Не, там заполнялась структура ModelData.
Но вам говорят о другом... нужно продумывать удобные механизмы использования своих классов и тестировать эти api, а что там под капотом не должно влиять.

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

PS почему меня так напрягает тест простых ф-ций - нигде у меня тестирование простых ф-ций не нужно. Ф-ция делает то-то и то-то и делает это хорошо. Вопрос в комплексе функций...

буст - говно


Я пишу класс, продумываю АПИ, делаю заглушки АПИ (ну там геттеры-сеттеры пишу сразу), пишу тесты на АПИ, потом заполняю класс. Это не совсем каноничное ТДД, которое требует написания теста до написания класса.
Макросы тестовых печатей - отличное тестирование:)

Которое никто не отменял  :)

Продумывание API развивается "по экспоненте". Тот же пример с obj - Вы можете и не знать что дальше делать с прочитанным, поэтому пока самое разумное - считать пачку контейнеров. Ну их конечно можно объединить в класс и назвать напр ModelData, но сути это не меняет. Только потом, когда полезете в glDrawElements, Вы обнаружите что вертексы надо "расшарить". Вот тогда да - нужно думать над API, для этого появились инфа/основания.

И там будет о чем подумать. Напр в obj файле фейсы могут иметь любое число вертексов. Как же их хранить и удобно рисовать (glDrawElements)? Слабонервные начинают лепетать "у меня только треугоооольники" - но Вы же не такой, правда?  :)

Вы опять перепутали API и внутреннюю реализацию.
К тому же это пример НЕ продумывания api вообще, от слова "совсем". Все что вы собрались обнаруживать потом, вы должны были обнаружить в дали от компьютера с блокнотом в руках, только после этого вы вообще можете о чем-то начинать думать. С этого момента проектирование только начинается.
А подход, сесть за компьютер, набрать в редакторе "class MainWindow" и открыть ТЗ на проект, исключает этап проектирования. Но лучше так не делать.

Программирование - слишком сложная интеллектуальная деятельность, чтобы можно было надеяться навязать ей узы административной системы. (Ван Тассел)

И еще... Никто не знает, в чем именно заключается тестирование, что является конечной целью и какие результаты следует получить. Принято считать тестирование законченным, если выполнение программы завершается кодом возврата 0, даже если исходные данные различаются хотя бы одним числом.  (СВН) :)

Вопрос сторонникам технологии тестирования: Как вы будете тестировать вот этот случай?

C++ (Qt)
 
float a = 123456789;
float b = 123456788;
qDebug() << a - b;
 

Размышления уровня джуниора. Если не знаете, то читайте умные книги. На такие дурацкие вопросы уже есть давно ответы.

Tuxford, читайте классические произведения.  ;)

Названия в студию.

судя по нашему последнему диалогу вы недалеко от этого джуна ушли:
не понимаете в чем заключается тестирование.

зависит от того, что именно нужно получить в результате.

Тестировать надо проблемные и потенциально проблемные места. А что должно быть параметрами и результатом, определяется контекстом задачи. Это невозможно формализовать и обобщить.

кстати, а что такое "нормальное тестирование" ?

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

в совокупности, имеется приложение для администрирования базами данных.

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

я сделал так:
1.
сначала покрыл тестами функционал компонентов работы с файловой системой.
там все просто: создать/удалить файл/каталог.
и что бы это выполнялось плюс/минус стабильно.
(аппаратными проблемами можно пренебреч)

2.
для гуя сбоку прилепил свою статическую систему сообщений,
что бы можно было "нажимать на кнопки" программно.
(MFC, родную систему сообщений для этих целей задействовать не получилось).


далее реализовал такую штуковину.

приложение запускается с аргументом командной строки:
в режиме тестирования, получает на входе текстовый файл с сценарием.

примерно такой дизайн:


вот это вот как называется?

Очень интересный подход. Есть класс Foo, Zoo, Koo, Loo. Все в кучу как-то связано. Образована какая-то многопоточная библиотечка. А теперь вопрос: как убедится что все эти классы работают правильно.
Никто не говорит, что на функцию лишь возвращающую результат надо писать юнин-тест. Не надо сводить хорошую идею до маразма.
Еще вопрос. А если дебаг возможен только printf'ом, тогда как проверить правильность работы?

Этот подход продиктован практической целесообразностью. ЧТО и КАК тестировать - это специфика проекта, в одном случае нужен один способ, в другом - иной. Иногда и дебаг через принтф дает очень много. Вы же не применяете один и тот же std::vector<double>, например, на все случаи жизни? Почему с тестированием должно быть по другому?

Потому что технологии тестирования уже давно отработаны. Изобретать велосипед нет нет смысла а не рассказывать что ТДД придумали коммерсанты.

Как Вы с помощью "некоммерческого" ТДД протеституете, например, коммуникацию с роботом? А GUI приложения? А систему, принимающую решения в реальном времени?

Немного не то. Вы говорите о функциональных тестах.
Коммуникаци, можно проверить. К примеру я поднимал простенький ФТП, делал проверку аплоада, реализованного через curl. Тестится на ура. При желании можно пойти дальше. Написать можно забабахать ФТП, который будет симулировать все нужные ситуации. Тогда вообще красота.

Для тестирования гуйни есть другие фишки. К примеру тестить html страници можно с помощью Селениума. Но, еще раз повторю, что это уже функциональное тестирование, а не юнит.

Правильно! Вот и Вы пришли к тому же - ТДД не может быть применимо для тестирования всего подряд (о чем так любят говорить особо упоротые адепты и сейлс-менеджеры). От себя скажу даже больше - там, где мне довелось работать, я ни разу, никогда не видел и не слышал, чтобы от ТДД был какой-либо профит. Проблемы - да. Пользы - нет. Либо потеря денег, либо времени, либо того и другого.

Возможно это справедливо для Вашего круга задач, но это случай не общий. Вот выше я привел пример простенькой задачки - чтение obj файла. В упор не вижу какой здесь прок от юнит-тестов. Гораздо лучше попросить юзеров накидать obj-файлов и прогнать каждый, визуально наблюдая полученную модель. Баги будут (и много), но совсем не те что ловились бы тестированием.

Сейл вообще не догадывается что это такое.
А я лично сам увидел. Особенно в больших проектах, с миллионами строк кода. В случае, когда жирная апликуха как-то интересно падает после 15 минут работы, с юнитестированием решается намного легче.
Или рефакторинг. Вот пример. Такого плана. Был себе движок для парсинга одного интересного файл. В моем случае информация о версиях. Номера версий изначально сохранялись в формате X.Y.Z. Тут сказали, что надо переделать на обычный X.Y.build. Как без юнит-тестов очень просто. Надо парсер версии переделать. Потом брать приложение, которое юзает это делать и проверять. Есть два приложения. Начали на одном тестить, вроде все хорошо. начали на втором тесть. Все хорошо. Дошло дело до приемочного тестирования. Тестировщики поковырялись и оказывается, что если к версии билда добавить буковку, хрен работает. Чтобы воспроизвести, надо сделать десяток телодвижений. Если бы были юнит-тесты, то скорее всего, там бы такой кейс был. А если не было, то добавить можно было проще. Т.е. когда уже поменяли функционал, запустил тесты и все. Минус одна проблема. Но нет, вместо того чтобы написать несколько простеньких строк текста, мы себе усложнили жизнь. Если бы таки случаев единицы. Ага, их немерено.

Проблема только одна: разработчикам лень писать примитивный код. В юинт-тестах ничего интеллектуального нет. В некоторой степени рутинная работа. Но так некоторые говорят что нафиг этот git.
По поводу потери времени, тысячу раз писал, что это компенсируется в будущем. Пример из одной конторки.
Когда только переходили на новый компилятор студии, сразу начинались проблемы. Любит мелкомягкий загрузит ненужной работой. Там где юнит-тесты были, проблемы решались в раз 5=-10(!) быстрее. И проблем было существенно меньше было. Старый код, где юнит-тестов не было, иногда отгрызал месяцы работы. 

Для вашего случае юнит-тестирование куда больше подходит. Куда проще накидать кучу маленьких файлов с определенной кривизной и проверять как ведется парсер в случае, скажем, отсутствие какого-то параметра. Или значение выходит за пределы. Или вообще файл подсунули не obj. Скажете такого не бывает? Недооцениваете изверей.  ;D

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

Думается в данном случае сочинять какие-то юнит-тесты - пустая трата времени. Вот примерно с чем Вы столкнулись бы на практике

- оказывается строки-то могут склеиваться слешем \
- оказывается индексы-то могут быть отрицательными
- оказывается одни фейсы могут иметь UV а др нет (противный случай)
и.т.д.

И вот, не зная этого, Вы наделали N тестов - ну и что, какая от этого польза? Надеяться что они как-то помогут при внесении изменений - так это в данном случае "стрельба по площадям"

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

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

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

ну вот, опять :(

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

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

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

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

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

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


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

Offtop'у :)


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да у меня много чего есть, но речь не о том. У меня нет никаких намерений с Вас "что-то получать" - покажите метод, разработку TDD, которую Вы так хвалите. А совать тесты (первые что пришли в голову) в чужие классы = пришивать к <template> рукав, не более того. Предложена задача которую не то что "джуниор", а студент(!) пишет за один день. Где же сила богатырская? Трепло Вы, вот и все. Умолкаю.