Здравствуйте, fmiracle, Вы писали:
F>Здравствуйте, FDSC, Вы писали:
FDS>>1. Когда я писал в VS 6.0 (на C++, понятно) я попытался сделать ЮТ: результат был поразительным: мой код был настолько отстойным, что отстойней просто некуда. Иногда создавалось такое впечатление, что я просто забыл, что и как хотел написать в коде. ЮТ просто выбили меня из задачи. После ещё нескольких попыток я понял, что ЮТ не для меня.
F>У меня тоже такое было. И тесты фиговые получались, и код корежило ужасно, чтобы обеспечить доступ тестам к нужной (как мне тогда казалось) информации. Забросил я их. Потом, набравшись опыта вообще и прочитав разных книг, включая книги про ЮТ — решил, что можно опять попробовать, ибо достало править глупые ошибки, для обнаружения которых надо забить длинную экранную форму в программе... И вот сейчас они уже начинают облегчать мне работу.
У меня не так: я ничего в архитектуре не менял. Просто меня выбивало из задачи.
F>Я, правда, перестал думать, что ЮТ обеспечат меня надежной и безошибочной программой, а стал относиться к ним как к средствую повышения скорости отладки. Точнее — скорости обнаружения и локализации ошибок. А так же — средство поразмыслить над тем, что же я вообще пишу — ЮТ я пишу одновременно с кодом (то сперва код, потом тесты, то наоборот — по ситуации, но примерно в одно время) — это не выбивает меня из потока, наоборот позволяет рассмотреть ситуацию с разных сторон и подумать о возможных слабых местах, а потом сразу посмотреть — нормально оно заработало оно или нет. Часто код и тесты вообще пишутся параллельно — тут придумал новый тест — и даже без запуска понял, что эта ситуация в коде не предусмотрена — пошел дописал, заодно придумал еще тест.
Да, такое действительно бывает. Хотя я пока обхожусь без автоматизации.
minorlogic wrote: > C>Обычно смотрится покрытие кода — то есть должна быть выполнены все ветки > C>условий. Обычно это делается без особых проблем. > Без проблем оттестировать DLL у которой одна функция типа Render, > которая читает определенные данные и рендрит.
Если функция читает и рендерит данные — то это пример плохого
проектирования. Либо надо тестировать уже не функцию Render, а
внутренние функции библиотеки (типа readData, renderData).
При этом корректность рендеринга проверять обычно бессмысленно.
Здравствуйте, Cyberax, Вы писали:
C>FDSC wrote: >>> > ANS>Мне не совсем понятно, как, в условиях недостатка времени, можно >>> > надеятся, что человек протестирует быстрее чем компьютер? >>> > Лекго и просто: тестировщиков побольше нанять, они стоят дешевле чем >>> > программист, который сделает хороший ЮТ >> C>Если это GUI-приложение, то еще можно. А если приложение — это компилятор? >> Хм. И как его протестировать Unit тестами? C>Так и тестируется пишутся unit-тесты для определенных частей. Например, C>у меня так тестируется разворачивание переменных и т.п.
НУ, хорошо. А как протестировать алгоритм нахождения кратчайшего пути в графе?
FDSC,
C>>Так и тестируется пишутся unit-тесты для определенных частей. Например, C>>у меня так тестируется разворачивание переменных и т.п.
FDS>НУ, хорошо. А как протестировать алгоритм нахождения кратчайшего пути в графе?
Обычно вычисляемый вывод сравнивается с ожидаемым.
Либо влазить в кишки... Это легко в данном случае, ибо алгоритмы Флойда и Дейкстры изучены вдоль и поперёк, и есть леммы о том, что некоторые соотношения сохраняются на каждом шаге алгоритма. Их можно вот проверять в принципе.
Но в более сложных случаях (я видел описание одного алгоритма для задачи теории расписаний — 40 страниц!) — только вышеуказанным способом.
Lazy Cjow Rhrr wrote: > Давай разберёмся, что это за гипотетический "другой код"?: > 1. Библиотечный — здесь количество ошибок напрямую зависит от умения > обращаться с библиотеками, и крайне не рекомендуется использовать > библиотеки непроверенным способом, я об этом упоминал.
Угу, согласен. Библиотеки нет смысла тестировать.
> 2. Наш код — здесь возникает вопрос: откуда взялось неизвестное > зацепление с кодом, который мы писали месяц назад? Вероятно мы > наколбасили уже целых 10Мб и /основательно забыли и не записали о > неочевидных условиях/, в которых работают классы из "первого" мегабайта > и неявных связях между ними.
Так ведь записывать ВСЕ неявные связи — невозможно. В моем примере
неявная связь была в структуре одного из списков. Таких примеров у меня
достаточно много.
> И теперь в новом классе мы создали нечто, > что нарушило гармоничную работу тех классов... Не спорю, такое возможно. > Но очень уж натянуто выглядит это... особенно для кода месячной давности.
У меня такое достаточно часто бывает, особенно в командной работе.
В нем есть куча случаев и этот код, вдобавок, еще и является performance
bottleneck'ом. При добавлении новой оптимизации нужно смотреть на то,
что она не сломает какой-то частный случай. Без тестов это делать было
бы оооочень жутко.
> Намёк на архитектуру: "Вася, зачем тебе доступ к этой коллекции?". > Почему она неочевидна? Намёк на соглашения и комментарии: "Петя, назови > методы retrieve*, а не xxx!".
Ну так в том-то и дело, что часто доступ к коллекции вполне очевиден и
нужен. В примере со stacktrace'ом была зависимость на структуру списка
фреймов — вполне логичная для интерпретатора вещь.
> Наконец, если старые классы ломаются, то может быть это неважно? Важный > код мы /всё-равно/ тронем, когда будем тестировать всё приложение.
Вопрос в том когда оно обнаружится. Вдобавок, при работе в
команде наведенные ошибки могут привести к тому, что отлаживать твой код
будет уже другой человек и займет это у него больше времени (скорее всего).
> А написание тестов с нуля?
В существующем проекте — скорее всего неоправдано.
> Даже одновременно с кодом? Возможно, что (тесты + отладка > < отладки), но определённо не в нашем случае.
Опять же, случаи бывают разные. Но если код поддается юнит-тестированию,
то оно обычно сокращает сроки разработки.
FDSC wrote: > C>Так и тестируется пишутся unit-тесты для определенных частей. Например, > C>у меня так тестируется разворачивание переменных и т.п. > НУ, хорошо. А как протестировать алгоритм нахождения кратчайшего пути в > графе?
Какой алгоритм? Волновик?
Пишем тест, который вызывает попадания во все ветки условий (их там
совсем немного).
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>FDSC,
C>>>Так и тестируется пишутся unit-тесты для определенных частей. Например, C>>>у меня так тестируется разворачивание переменных и т.п.
FDS>>НУ, хорошо. А как протестировать алгоритм нахождения кратчайшего пути в графе? LCR>Обычно вычисляемый вывод сравнивается с ожидаемым.
LCR>Либо влазить в кишки... Это легко в данном случае, ибо алгоритмы Флойда и Дейкстры изучены вдоль и поперёк, и есть леммы о том, что некоторые соотношения сохраняются на каждом шаге алгоритма. Их можно вот проверять в принципе.
LCR>Но в более сложных случаях (я видел описание одного алгоритма для задачи теории расписаний — 40 страниц!) — только вышеуказанным способом.
Вот в этом вся и проблема. Для того что бы писать ЮТ нужна или хорошая теория, которая позволяет проверить по косвенным данным правильность выполнения (а если теории нет, ведь задачка сразу очень тяжёлой становиться) или проверять по посчитанному вручную набору данных.
В итоге получается, что, лично у меня, все ЮТ сводятся к автоматизированной загрузки заранее подготовленных в ручную save'ов и автоматизированному же сравнению сохранённого результата с эталонным.
Здравствуйте, Cyberax, Вы писали:
C>FDSC wrote: >> C>Так и тестируется пишутся unit-тесты для определенных частей. Например, >> C>у меня так тестируется разворачивание переменных и т.п. >> НУ, хорошо. А как протестировать алгоритм нахождения кратчайшего пути в >> графе? C>Какой алгоритм? Волновик?
C>Пишем тест, который вызывает попадания во все ветки условий (их там C>совсем немного).
Не понял, что проверяется и что от этого будет? Ведь я могу случайно (у меня такое действительно было) вместо < поставить >, и ЮТ уже ничем не поможет тогда.
У меня в алгоритме никаких веток, собственно нет. Там можно проверить только что вообще по всем узлам прошёл. Да и то будут ложные срабатывания, если граф несвязный. Для меня ложные срабатывания в ЮТ самая большая проблема была, когда я ими пытался пользоваться.
Впрочем, я только для примера привёл именно этот алгоритм.
FDSC wrote: > C>Пишем тест, который вызывает попадания во все ветки условий (их там > C>совсем немного). > Не понял, что проверяется и что от этого будет? Ведь я могу случайно (у > меня такое действительно было) вместо < поставить >, и ЮТ уже ничем не > поможет тогда.
Для этого надо сравнивать результирующие данные с эталоном.
> У меня в алгоритме никаких веток, собственно нет. Там можно проверить > только что вообще по всем узлам прошёл. Да и то будут ложные > срабатывания, если граф несвязный. Для меня ложные срабатывания в ЮТ > самая большая проблема была, когда я ими пытался пользоваться.
Проблема с алгоритмической корректностью — это уже совсем другая история.
Юнит-тесты нужны для проверки непосредственно правильности кода.
Здравствуйте, Mirrorer, Вы писали:
LCR>>5. Статическая типизация в сочетании с IDE работает удовлетворительно и без тестов. M>+1 Но статическая типизация в сочетании с ИДЕ и с юнит тестами работает лучше чем удовлетворительно.
Мне кажется, что это (выше) ключевой момент дисскуссии вызывающий несогласие в станах оппонентов.
Суть его проста.
1. Есть люди которые вообще считают тестирование пустой тратой времени. Таких очень мало и скорее всего они просто по другому понимают этот термин. Тестирование у них есть но выглядит оно по другому.
2. Есть люди которые говорят как ты. Если высказаться более конкретно то это будет звучать так "Любые средства повышающие надежность кода хороши и полезны." При этом по хорошему надо добавлять "...если при этом они не создают проблем больше чем решают."
3. Есть люди которые считают, что без юнит-тестов жить нельзя и все кто их не делает м... ну, опистим это . В большинстве влучаев такие люди пишут на скриптовых или небезопасных (почти синоним С++ ) языках и не используют продвинутых IDE.
4. Есть настоящие маньяки TDD/XP. Эти вообще ничего не аргументируют. Их высказывания зачастую верны, но в общей массе они представляют религиозную пропаганду. В их речи нужно верить или нет.
Кстати, часто упоминаемый Фаулер мною относится ко второй категории, хоят многие считают его членом четвертой. Все же Фаулер довльно разумен и не столь радикален. Он продвигает многие средсвта повышающие качество кода. TDD только одно из них. Например, DSL-и он продвигает не хуже.
Так вот проблема в том, что многие из тех кто тут во всю ставит оценки своим оппонентам на самом деле всего лишь пытаются прикрыть свои радикальные взгляды.
Они используют юнит тесты для защиты, например, нетипизированных и опасных языков. В обсуждении тем связанных со статической типизации они постоянно принижают ее значения кивая на то что мол без юнит-тестов вообще не жить, а раз так то зачем тогда все эти проверки комиилятора. Все равно юнит-тесты все проверят.
Я тоже придерживаюсь позиции из второго пункта. Более того считаю что статическая типизация и безопасный язык даже более важны чем сами юнит тесты. Хотя я не склонен противопоставлять одно ругому. Тесты проверяют динамику, а система типов статику.
Если взять тот же рефакторинг, то по моему мннеию статическая типизация и поддержка IDE здесь играют даже большую роль. Конечно юнит-тесты могут только помочь рефакторингу добавив контроля за ситуацией, но все же они не способны именно помочь и темболее автоматизировать рефакторин. Меж тем если рефакторинг можно произвести силами IDE, то никакой дополнительный контроль в общем-то и не потребуется, а сам рефакторинг будет произведен в щитанные секунды. Те кто использует автоматизированный рефакторинг повседенвно так к нему привыкли, что даже незадумываются над тем, что их оппоненты не понимают этог, а стало быть оба лагеря недооценивают значимость автоматического рефакторинга.
Но даже если автоматический рефакторинг невозможен статическая типизация повзоляет существенно сократить объем работы и в особенности объем отладки, так как многие ошибки автоматически отлавливаются системой типов. При этом компилятор (особенно если он хороший) показывает места ошибок и содествует пониманию совершенной ошибки. Это позволяет устранять ошибки быстрее. Конечно, мы тратим какое-то время на борьбу с ошибками компиляции, но если это не бессимысленные награмождения ошибок вызваемых С++-компилятором в следствии вольной трактовки очередного супер-шаблона, то мы довольно быстро устраняем их. При этом значительно согращается этап отладки. Это намного лучше чем несработавший юнит-тест. Юнит тест только отлавивает ошибку. И не всегда из этого понятно в чем ошибка, и как ее отловить.
Далее юнит-тесты все же сами по себе вызвают проблемы. Как бы кто не говорил, что это все мелочи, но юнит-тесты сами требуют написания, отладки и рефакторинга. В случае рефакторина они усложняют этот процесс. Бывает даже так, что тест путает. Ведь мы априори воспринимаем тест как верный. А возмоно ошибка в нашем предположении. При этом видя зеленый кружочек мы думаем "Все ОК! Ошибок нет, или ошибка просто не охвачена тестами. Будем копать...", а на самом деле ошибка находится в юнит-тесте и программист подтасовал результат кода под эту ошибку. Причем в рамках тество пробелем нет, но в реальном использовании они таки могут вылезти. Это уже наложенная ошибка. Так называемая — ошибка второго порядка.
Ну и главное, юнет-тесты не отлавливают всех ошибко и не делают программу корректной. Они позволяют ввести дополнительный контроль. Это нужно четко понимать. А многие поклонники TDD молятся на них.
Есть разные задачи. Для одних юнит-тесты удобны. Для других неприменимы. Для теретих бессмысленны. Так нельзя проверить ГУИ юнит-тестами. Создание МОК-объектов тут является полнешей глупостью. МОК-объекты будут заменять ГУИ. Так что мы будем тестировать прикладной код, а не ГУИ. Меж тем для тестирования ГУИ есть мощьные средства втоматизации (стоящие не мало денег, однако). Так же бесполезны юнит-тесты при разработке систем с динамической логикой. Точнее они не бесполезны. Выгоду от юнет-тестов можно получить и тут. Вед динамическая логика состоит из частей. Эти части тоже нужно писать, отлаживать и контролировать. Но к сожалению проверить юнит тестами кореектность таких систем нельзя. Тут нужны пакетные тесты содержащие много сложных сочетаний. Конечно и их можно назвать юнит-тестами, так как мы в итоге проверям результат пакетного теста с ожидаемым, но вот написать такой тест невозможно, да и не является он уже "Юнит". Он контролирует уже массу аспектов, а не какй-то один.
Так вот тестирование важно. Без него никуда. Но как не странно бывает (и часто), что лучшим тестированием является прикладное использование. Я часто замечал, что продукты лучше если их используют те кто пишет и если пользователи могут напрямую воздействовать на разработчиков.
Так что юнит-тесты — это инструмент повышения качества кода. Не болше и не меньше. Не надо низводить его до полной никчемности, но и не стоит делать из него религию и строить свою разработку исключительно отталкиваясь от них.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Не волнуйтесь. Если Вам удается работать без юнит-тестов и при этом хорошо зарабатывать, продолжайте в том же духе. Кто такие эти Эскель, Фаулер, Бек ? Они — Ваши клиенты ? Они Вам плотют деньги ? Если нет, то они не выражают Вам требования, а лишь высказывают свое мнение опираясь на свой опыт. С их мнением можно считаться. А можно не считаться. А уж опыт — он у всех очень очень разный.
Что касается юнит-тестов. Это всего-лишь одна из методик, которая может облегчить Вам жизнь. А может не облегчить. Применять ее или нет — решать Вам. По моему опыту, юнит-тесты обладают следующими достоинствами и недостатками:
Достоинства
1) Заставляют продумывать заранее, что нужно запрограммировать (test-first).
2) Заставляют строить модульные системы.
3) Действительно улучшают качество выходного продукта.
4) Создают приятное (ложное) ощущение, что проект работает верно.
Недостатки
1) Вводят в ступор (тут без теста бы сообразить, с какого вообще конца браться, а ты гришь test-first...)
2) Требуют дополнительных усилий на их написание
3) Стремятся сделать проект менее гибким, а именно:
3.1) Требуют времени на пожжержание дополнительного кода
3.2) Требуют времени на согласование изменений в коде и тестах
4) Создают ложное (приятное) ощущение, что проект работает верно.
В моей практике очень часто возникают такие ситуации, когда изменения в коде влекут такие катастрофические изменения тестов, что я просто начисто вырезаю с мясом целые тест-сюиты, так как не вижу смысла их поддерживать в дальнейшем.
Не поддавайтесь на провокацию о 100% покрытии приложения тестами. Это утопия. Не бывает 100% покрытия по вполне понятным причинам комбинаторной сложности задачи. Юнит-тесты немного, конечно, снижают комбинаторную сложность за счет того, что работают не со всей программой, а с ее частями, но все равно, сложность написания тестов в неокоторых случаях превосходит сложность реализации. А это глупо. Лучше я два раза напишу одну и ту же программу по разному и буду сверять результаты — это будет надежнее.
Да и вообще. Вы сами уже ответили на все вопросы, когда сказали что worse is better. Мы будем делать то, что надо [клиенту], а того, что не надо [клиенту] мы делать не будем. А ему часто по барабану все эти тесты, красивая архитектура, запредельное качество. Клиент у нас с Вами — не министерство обороны с встроенными системами на подлодках, клиент у нас простодушный Большой Босс Владеющий Банками Заводами Пароходами, делайте то что ЕМУ важно, а на то, что программа вываливается в корку, когда пытаешься на сааамый удаленный пункт меню нажать он (клиент) даже внимания не обратит. А если обратит, честно признаем, что она (программа) не идальна, у всех свои недостатки. Клиент поймет.
Все. Написал бы больше, но нужно идти циферки складывать и денежки со счета на счет пересыпать... Большого Босса ублажать
Проблему подметил верно, а вывод не верный сделал. Рефакторить надо для уменьшения сложности решения. Для увеличения ясности. Эти факторы не могут затянуть время разработки проекта. Если проект сложный, то уменьшение его сложности без потери функционала — это увеличение скорости его завершения. Ведь в ты экономишь не на мелочах, а что называется повровым методом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, DarkGray, Вы писали:
DG>юнит-тесты нужны только, если модуль — хандрит, причем как только модуль заработал, юнит-тесты можно выкинуть в помойку.
По-моему, юнит-тесты можно применять как средство отладки сложных вещей. Например, в приложен может быть не так просто воспроизвести некое состояние. А юнит-тест может делать это за считанные милисекунды.
Удалять его после завершения отладки смысла нет. Можно просто ввести более общие тесты, а юнит-тесты проганять только изредка или когда нужно вернуться к работе с тем состоянием.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mishaa, Вы писали:
M>Угу, в частности про то что в этом месте может отвалится помнит только юнит тест.. а люди как правило забывают.
Большой пакетный тест тоже может помнить. Например, если мы пишем компилятор, то о том, что что-то отвалилось напомнит попытка скомпилировать самого себя или другой объемный проект.
Так что юнит тесыт тут соревнуются скорее с системой типизации, та как они могут более четко указать на проблему. И при таком взгляде на проблему юнит-тесты по сути являюся плохо реализованными системами ограничения типов (контрактов).
На контракты можно смореть как на продолжение описания типа. Просто сам тип это структурный контракт, а "конктракт" — это алгеброический контракт проверяющий модель поведения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Laughing_Silencer,
L_S>Автора цитировать не буду, поскольку с большей частью его выводов интуитивно согласен. Есть области разработки, где тестирование действительно полезно — это пожалуй библиотеки и алгоритмы, но все же помимо ИМХОв людей участвующих в дискуссии хотелось бы получить некую статистику.
L_S>Кто нибудь знает статистику по проектам выполняемым с использованием юнит тестов ? Т.е. не теоретические выкладки, а именно статистика по реальным проектам.
+1;
особенно мне интересно было бы увидеть статистику по видам ошибок в условиях современных средств разработки. Нигде не нашёл...
borisman3,
B>Не волнуйтесь. Если Вам удается работать без юнит-тестов и при этом хорошо зарабатывать, продолжайте в том же духе.
B> А ему часто по барабану все эти тесты, красивая архитектура, запредельное качество. Клиент у нас с Вами — не министерство обороны с встроенными системами на подлодках, клиент у нас простодушный Большой Босс Владеющий Банками Заводами Пароходами, делайте то что ЕМУ важно, а на то, что программа вываливается в корку, когда пытаешься на сааамый удаленный пункт меню нажать он (клиент) даже внимания не обратит. А если обратит, честно признаем, что она (программа) не идальна, у всех свои недостатки. Клиент поймет.
Положа руку на сердце хотелось бы делать что-нибудь хотя бы приблизительно напоминающее (по надёжности) AXD 301 Но ресурсы малы и возможности не те...
B>Все. Написал бы больше, но нужно идти циферки складывать и денежки со счета на счет пересыпать... Большого Босса ублажать
Да, да, я тоже примерно это же.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
A>>Если код не протестирован, то как можно говорить о том, что он работает правильно? LCR>Очень даже можно. Как я и говорил, убедиться в том, что он работает, можно наличием другого тестирования. Проверяются все варианты использования, какие нужны, а работа программы при -273'C не требуется. Предлагаешь вместо создания руля и приборной доски устраивать крэш-тесты?
Опять тоже самое упущение, мы не проверяем работу программы, мы проверяем правильность работы кода. С этой стороны также неверно говорить о тестировании GUI, потому как GUI — это не код. Нельзя тестировать БД — это тоже не код. Юнит-тестами тестируем только код.
(На самом деле фраза построена специально, чтобы напомнить стиль книг Фаулера и Бека, но её не надо воспринимать в таком виде Главное идею обобщить.)
Есть ещё такая метафора для юнит-тестирования как "проверка грамматических правил". Орфография в тексте проверяется фактом компилирования программы, а грамматика — покрывается правилами языка (тестами). И затем если вставить куда-то в середину фразы дополнительные слова, то редактор в случае грамматически неверно построенных предложений подчеркнёт предложение и его можно как-то исправить, до тех пор пока ошибка не исчезнет. Вот только для кода нельзя построить список конкретных правил и этим занимается программист, а для письменности — это всё же возможно. Вот я грамматические ошибки в тексте очень не люблю .
Ну а метафора, как и любая аналогия — неверна по определению
Для тестирования работоспособности программ существуют функциональные тесты, которые и правда могут быть заменены бригадой QA.
A>> Отсюда и рождается болезненное восприятие изменения этого кода, потому как неизвестно как себя поведёт этот код при банальных изменениях в нём, а уж о сложных и говорить нечего, а тесты позволяют видеть как ведёт себя код при изменениях. LCR>Свежий код меняется достаточно легко — мы его только что написали и помним все трещинки.
Угу, так как я часто пишу реализации алгоритмов (криптография в основном), то свежий код даже только что написанный не так то и легко запоминать по всем трещинкам. Особенно когда опасность его сломать заключается практически в любом изменении. На этом опыте просто хорошо очень это замечается, но я переношу это и на другие проекты, хотя там это не так заметно, и действительно, чтобы сломать только что написанный код в таких проектах нужно постараться.
A>>Тесты прежде всего нужны, чтобы было психологически легче изменять уже написанный код и удостоверятся, что при этом ничего не сломалось. Автоматический рефакторинг заменяет тесты при нефункциональных изменениях кода (то есть в средах, где автоматический рефакторинг отсутствует, уверенность работоспособности кода остаётся только на тестах). При функциональных же изменениях без тестов на работоспособность уже не обойтись. LCR>Ты прав, и это не противоречит моим словам — в длительной перспективе тесты необходимы. Я же говорил о срочных проектах.
Понятие срочности очень растяжимое. Если "срочное" — это утилита, которая пишется два дня, выкидывается на использование и забывается, то конечно согласен, что тут тесты просто не успевают появиться (если конечно не используется методика TDD). Но если программа далее передаётся ещё и QA и затем наверняка возвращается для исправления ошибок, то, о каком же таком "срочном" проекте идёт речь?
Еще, например я не пишу тестов для прототипов, потому как там действительно они только мешают быстро создавать эти самые прототипы.
P./S.: Напоследок ещё такое наблюдение:
Отсутствие успешно отрабатывающих юнит-тестов говорит о халатности работы в команде, практически точно также как и коммит в репозиторий некомпилирующегося кода.
Здравствуйте, VladD2, Вы писали:
VD>Так вот тестирование важно. Без него никуда. Но как ни странно бывает (и часто), что лучшим тестированием является прикладное использование. Я часто замечал, что продукты лучше если их используют те кто пишет и если пользователи могут напрямую воздействовать на разработчиков.
Из этого следствие: программы должны писать пользователи, а не программисты
Здравствуйте, Cyberax, Вы писали:
C>minorlogic wrote: >> C>Обычно смотрится покрытие кода — то есть должна быть выполнены все ветки >> C>условий. Обычно это делается без особых проблем. >> Без проблем оттестировать DLL у которой одна функция типа Render, >> которая читает определенные данные и рендрит. C>Если функция читает и рендерит данные — то это пример плохого C>проектирования. Либо надо тестировать уже не функцию Render, а C>внутренние функции библиотеки (типа readData, renderData).
C>При этом корректность рендеринга проверять обычно бессмысленно.
Вот на эту мысль я и пытался навести , что тестировать наиболее удобно маленькие отдельные модуле , а если сам тест встроен еще и в исполняемый код , то это почти идеально. И разделять юнит тесты в некое отдельно приложение не всегда разумно.
Т.е. Я не говорю о том что ЮТ плохи , я говорю о разумном подходе. Например я бы при тестировании смарт поинтера применил несколько подходов
1. АССЕРТЫ внутри реализации.
2. Тесты на функциональность. (копирование самого в себя и т.п.)
3. Тесты со специальными классами , которые подсчитывают к-во копирований конструкторов и деструкторов.
VD>Удалять его после завершения отладки смысла нет. Можно просто ввести более общие тесты, а юнит-тесты проганять только изредка или когда нужно вернуться к работе с тем состоянием.
вот именно: если будет нужен, то его надо будет отрыть в дебрях vcs, сдуть нафталин и заставить работать.
но пока тест не нужен — каждодневно на него тратить время на сопрождение, запуск и трактовку результатов — не имеет смысла.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Но статическая типизация в сочетании с ИДЕ и с юнит тестами работает лучше чем удовлетворительно. 
Но ресурсы малы и возможности не те...
.
