No translations available for this entry
Навеяно предыдущим постом.
А вот скажите мне, коллеги, кто-нибудь вообще использует юнит-тесты при разработке? Имеется в виду нормальный, “почти полный”TDD, когда тестами не покрыто только то, что ими не покрыть, а не “пишем, когда менеджер заставляет”?
P.S. Лично я вообще без юнит-тестов уже писать не могу. Как показывает опыт, стоит предположить, что это настолько просто, что накосячить там просто невозможно, как обязательно отрастает какой-то глупый косяк. Ну, вроде “if (i=a) {}”. А уж сколько всего можно навылавливать из чужого кода, в котором юнит-тест только один и то только потому, что манагер приказал, я мог бы рассказывать часами.
На предыдушем проекте у нас были не только тесты, но и code review как обязательная часть чекина (под чекином должно стоять 2 имени девелоперов, плюс имя тестера), билд после каждого чекина, который если сваливается, видно всем сразу, запускались тесты (невыполнение которых само собой сваливало билд), запускался FxCop, (кажется его высокий показатель билд тем не менее не сваливал, не помню уже), и показывался test coverage и количество warnings из-за неоткомменченного кода, за что давали по рукам даже больше чем за недостаточное количество тестов.
В пред-предыдущем было почти так же, причем была куча тестов для про-кликивания приложения, которые приходилось постоянно поддерживать.
В текущем месте к етому постепенно идут тоже.
На предыдушем проекте у нас были не только тесты, но и code review как обязательная часть чекина (под чекином должно стоять 2 имени девелоперов, плюс имя тестера), билд после каждого чекина, который если сваливается, видно всем сразу, запускались тесты (невыполнение которых само собой сваливало билд), запускался FxCop, (кажется его высокий показатель билд тем не менее не сваливал, не помню уже), и показывался test coverage и количество warnings из-за неоткомменченного кода, за что давали по рукам даже больше чем за недостаточное количество тестов.
В пред-предыдущем было почти так же, причем была куча тестов для про-кликивания приложения, которые приходилось постоянно поддерживать.
В текущем месте к етому постепенно идут тоже.
Я использую. Ну во всяком случае пытаюсь.
Я вне работы использую. На работе менеджеры пока не определились, хотят они Unit testing или нет.
Я на работе использую вне зависимости от мнения менеджеров, ибо это, по большому счету, не их дело
Ну, пока тенденция намечается обнадеживающая, если честно
Я на работе использую, потому что без них мне в 5 раз сложнее. Менеджеры и остальные два разработчика по-моему о их существовании не особо догадываются вообще.
Ну, по крайней мере теперь я точно знаю, что не идиотъ (с)
Ну как, вообще-то их тоже. Они так или иначе мне за время платят, если они не хотят, чтобы я его на тесты тратил - тут уже ничего не поделаешь.
Постой, постой. Тесты - это часть процесса разработки. Нельзя разрабатывать код без тестов. Если не хотят, чтобы программист “тратил время”, он будет “проводить время” в отладчике, получая на выходе unmaintainable код.
Тесты, конечно, не silver bullet, но если манагеры решают “не тратить время”, то самым верным решением будет перестать тратить время на эту контору. А то завтра они еще чего в таком духе решат вроде запрета STL или boost.
Ну как сказать, если код без тестов разрабатывался всю жизнь компании и особых проблем с ним не было (разработчиков только хороших нанимают :), то они просто не видят проблем с текущим положением дел. И потом, да maintainability страдает немного в смысле того, что после рефакторинга раз в год вылезает какая-нибудь проблема, но она чаще всего находится в ближайшие несколько дней. Код действительно хороший, костяк был написан одним очень умным человеком и bug free давно, остальные части друг от друга не зависят и ошибки 99% времени изолированы. Рефакторинг в основном только локальный и проводится крайне редко. То есть тесты как бы действительно не нужны.
То есть, есть один и то, они очень долго сопротивлялись, утверждая, что разработчики будут на него надеятся и код хуже писать 
Я могу даже больше сказать, в компании и обычных тестеров нет
И несмотря на все это, в компании разработана линейка больших (полтора миллиона строк кода) С++ приложений, которые работают очень стабильно. Просто вот так повелось.
PS. Вообще, мне кажется тесты нужны только когда есть шанс достаточно обширных переделок кода при том, что существует strong coupling внутри него. Если нет рефакторинга или связности, они как бы не сильно нужны, просто потыкать по кнопочкам полчаса после компиляции и проверить edge cases достаточно. Но это лично мое мнение
Очень нужное. Если в приладе наступает момент handover, то дальше без тестов при прогрессивном индокодинге никто уже не поручится что и где полетит со следующим CR. А потом влетают дорогие контракторы и лудят рассыпающееся софто
Через какое то время все это надоедает и прогу пинками загоняют в утиль ибо с нуля уже начинать проще.
Loose coupling тоже можно превратить в приладу с 1000 конфиг файлов, которые под страхом казни нельзя трогать )
А если над прогой все еще трудятся гении отцы основатели, то ничего все дышит без юнит тестов - видел и такое.
А что народ использует как фреймвок для юнит тестов?
И еще, как вы делаете юнит-тесты для сильно-гуишного кода?
svox: У нас как раз случай с отцами-основателями
Но с другой стороны, я например ничего близкое к ядру проекта трогать без code review с разработчиками этого самого кода трогать просто так не решусь, даже если бы тесты были кстати, потому что тестируется всегда не все.
svox: У нас как раз случай с отцами основателями. Но опять же, я даже с тестами не решился бы изменять код близкий к ядру проекта, без консультации с его автором, просто потому что тесты не могут все полностью покрывать.
С контракторами сложно, мне кажется у нас работают люди, лучше которых сложно кого-то найти. Единственный контрактор в проекте, которым все в принципе довольны, никогда string через ссылку не передает, всегда по значению
И после того, как у него два винчестера за неделю до релиза сломались подряд, у меня появились нехорошие подозрения…
Vadim, тебе, похоже, повезло работать в несуществующей компании.
Бо обычно как бывает. Есть ведро системы, написанное дцать лет назад отцом-основателем, которое и правда работает очень стабильно (хотя никто никогда не пробовал подсунуть вооон той функции на вход вооот такую длинную строку), но дцать/2 лет назад отец основатель отошел от дел и стал каким-нибудь CEO, а код после него попал в руки кому попал. Получившуюся кашу порой даже спагетти-кодом не назовешь.
Более того, тесты веть не только и не столько для проверки, сколько для разработки. Вот, говорят, программы нынче пишутся не для компьютеров, а для других программистов. На мой взгляд, тесты очень помогают в случаях, когда нужно сделать сложное простым, когда тебе нужно написать нечто, а ты изначально даже не представляешь, как это можно сделать так, чтобы этим можно было удобно пользоваться. Вот тогда пишется сначала тест, а логика подгоняется уже под него. Обнаруживаешь, что как-то неудобно, быстренько все меняешь, тест тут позволяет тебе самому побывать в шкуре того, кто потом будет твой код использовать.
Я вообще исторически использую cppunit, но сейчас на проекте мы заюзали MSTest, генерим mixed-mode dll. Обнаружились проблемы - класс теста другом не сделать; MSTest, несмотря на красивости в гуе, оказался тем еще поделием пера майкрсофтова - как сделать так, чтобы он автоматически запускался после билда и обваливал билд если тесты мадают, совершенно непонятно, не говоря уже о том, что в случае красного теста прыгнуть сразу на строчку кода, где ассерт сработал, невозможно - вместо этого в лучших традициях мелкомягких окрывается отчет, где тебе показывают стек, как правило, стек того ассерта. Очень информативно и чрезвычайно “удобно”.
Ну да, у нас основатель без претензий, ему и программистом неплохо работается
Я вообще согласен насчет тестов, я потому их в сторонних проектах и использую. Но просто и без них жить можно, если очень хочется. Иногда хуже, иногда так же, как, например, в нашей ситуации. Может быть даже чуть-чуть лучше за счет свободного времени потраченного на разработку, а не на написание тестов.
Я просто не люблю когда из них серебрянную пулю делают, или когда говорят
потому что это принципиально не правда. Я эти слова никому не навязываю, в подкасте от Microsoft employee недавно слышал просто
Вообще, это мне все историю с ООП напоминает, все говорят, без объектов жизни нет, а вот ядро Линукса и движок Quake написаны на C и работают. Ну просто потому, что так получилось
Ну, вообще говоря, проавильно поставленное юнит-тестирование позволяет подойти к релизу с уверенностью, что кофеварка действительно варит кофе, а не борщ и не расходует при этом две Warragamba dam на чашку кофе.
Но тестирования это никак не отменяет, просто помогает перенести баг-репорты из области “оно все упало в синий экран, сожрав терабайт памяти” в область “клиент на самом деле хотел пуговицы перламутровые, а туалетную бумагу из наждачки номер 4″ гораздо быстрее.
Кстати, мы только что заопенсорсили наш тестовый фрейморк:
http://googletesting.blogspot.com/2008/07/announcing-new-google-c-testing.html
http://code.google.com/p/googletest/