[истории успеха] Разработка через тестирование

Ни разу не пожалел. Но у меня проект идеально вписывался в такую парадигму. Самый приятный side-эффект: уверенность в завтрашнем дне.

А по времени это как?

Лорчую вопрос.

> Какие могут быть подводные камни?

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

Если начинать работать в таком стиле, то какую тактику посоветуете?

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

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

TDD отлично идет если вышел на некую прямую разработки - инфраструктура проработана, доменная область ясна. Фигачишь тесты, реализовываешь фичи, красота.

а любые изменения будут адом.

Если какое-то изменение становится адом из-за изменения большого количества тестов, то проблема в том, что изменение слишком серьезное, а не в том, что есть тесты. Тесты как бы тебе кричат о серьезности изменения. Ну будь тестов ты бы просто переколбасил код в слепую на авось.

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

И да:

Код тестов будет в три раза больше самого приложения,

Ты так говоришь, буд-то в этом есть что-то плохое :) Да, суровая правда такова: хочешь сделать конфетку, придется долго и упорно работать, «на скорую руку» только говнецо делается.

> Ну будь тестов ты бы просто переколбасил код в слепую на авось.

Ты по себе об окружающих не суди. Я вооще «код в слепую» не «колбашу».

Ну ок. А какая альтернатива? Предложи схему более надежную, чем тесты. Без тестов мне видится что будет частично переписанное приложение, которое нужно тестировать вручную с нуля. Я верю что ты очень-очень стараешься, когда пишешь код. Но пока нету везких аргументов в пользу того, что он работает как нужно, то это таки «в слепую».

>> Код тестов будет в три раза больше самого приложения,

Ты так говоришь, буд-то в этом есть что-то плохое :)

А оно тут есть - обилие говнотестов висит грузом на интерфейсах, и когда их надо отрефакторить, возникает желалание этого не делать, чтобы не дрочиться с тестами. Отсюда мораль: тесты - кандалы на ногах рефакторинга.

Да, суровая правда такова: хочешь сделать конфетку, придется долго и упорно работать, «на скорую руку» только говнецо делается.

Суровая правда такова, что вместо обезьянних тестов на проверку «2+2», или бессмысленного и беспощадного байтодрочерства под чутким руководством рэндома, лучше потратить это время на вычитывание собственного кода, поиск багов и правку стиля.

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

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

> А какая альтернатива?

См. пост выше.

Суровая правда такова, что вместо обезьянних тестов на проверку «2+2», или бессмысленного и беспощадного байтодрочерства под чутким руководством рэндома, лучше потратить это время на вычитывание собственного кода, поиск багов и правку стиля.

Мы меня с кем-то путаете. Я не говорю, то тесты это такая альтернатива тому, что бы писать хороший код. Нет никакого «вместо»: нужно потратить достаточно времени и на вылизывание основного кода и на вылизывание тестов.

[истории успеха] Разработка через тестирование

Кто-нибудь применял данную методу?

было дело

Какие могут быть подводные камни?

камни обычные, обычно либо начинают работать с нарушением технологии и фейлятся, либо считать что это панацея от всего и снова фейлятся

Если начинать работать в таком стиле, то какую тактику посоветуете?

насчёт тактики скажу так - никогда не пишите код допрежь теста, это правило #1

а вообще, начните отсюда

См. пост выше.

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

А по времени это как?

после некоторого уровня всё быстрее и быстрее за счёт снижения завтрат на отладку

а вообще, умеючи оверхеда практически нет

Код тестов будет в три раза больше самого приложения,

и в чём проблема

а любые изменения будут адом.

только если тесты спроектированы неправильно

Написать тесты не спроектировав покрываемый кусок кода нельзя.

можно, TDD именно про это, но не надо говорить, что надо отключать моск

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

кто мешает написать прототип?

А оно тут есть - обилие говнотестов висит грузом на интерфейсах, и когда их надо отрефакторить, возникает желалание этого не делать, чтобы не дрочиться с тестами.

я только одного не понимаю - зачем писать именно говнотесты? :)

редактирование api - всегда трудоёмкая задача, на то оно и api

> а вообще, начните отсюда

Там описание какого-то культа.

> «Вылизанность» помогает отловить ошибки во время написании, но не дает никаких гарантий. А тесты кое-какие гарантии дают: если тест прошел, то код успешно верифицирован.

Это типичная методологическая ошибка. Первая аксиома тестирования гласит: тесты могут доказать наличие ошибки, но не могут доказать её отсутствия.

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

Нет-нет, это именно что та же самая. Если тесты не служат проверкой корректности приложения, то зачем они нужны? Вселять в программиста слепую веру, что «всё правильно»?

Это не риторический вопрос, я реально видел людей, которые на претензии заказчика «фича не работает» отвечали «у меня все тесты прошли».

Там описание какого-то культа.

секты работающего программного обеспечения

>> Код тестов будет в три раза больше самого приложения,

и в чём проблема

В поддержке. Всегда ваш, кэп.

а любые изменения будут адом.

только если тесты спроектированы неправильно

Т.е. на ряду с проектированием приложения разарботчку надо еще запариться на проектирование mockery?

Первая аксиома тестирования гласит: тесты могут доказать наличие ошибки, но не могут доказать её отсутствия.

зачем же тогда всё это тестирование придумали?

Если тесты не служат проверкой корректности приложения, то зачем они нужны?

во-первых, Вы путаете модульные и приёмочные тесты, а во-вторых писать модульные тесты гораздо эффективнее, чем каждый раз заниматься запуском дебаггера и рассматриванием закорючек\

Это не риторический вопрос, я реально видел людей, которые на претензии заказчика «фича не работает» отвечали «у меня все тесты прошли».

все мы видели олигофренов от профессии, но что это доказывает?

>> Код тестов будет в три раза больше самого приложения,

и в чём проблема

В поддержке.

простите, какая поддержка требуется модульным тестам?

>> а любые изменения будут адом.

только если тесты спроектированы неправильно

Т.е. на ряду с проектированием приложения разработчку надо еще запариться на проектирование mockery?

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

если тесты получаются кривые или не сходятся - это означает, что надо внимательно посмотреть на архитектуру приложения, в 9 из 10 случаев проблемы там

> я только одного не понимаю - зачем писать именно говнотесты? :)

Лично я не видел не говнотестов. И моё объяснение этому факту просто - сделать не говнотесты как правило в разы сложнее, чем решить саму задачу, которую эти тесты должны тестировать. Ведь дьявол то на самом деле не в 2+2, а в интеграции. А полноценные инеграционные тесты - это будет 1) полный звиздец 2) замена тестировщиков.

Самое серьёзное обоснование для тестодрочерства, которое вижу лично я, - хроническое не понимание работы нижележащего кода, и отсюда его боязнь. Люди, как известно, боятся того, чего не понимают. Вот и крестяться^W пишут тесты.

Лично я не видел не говнотестов.

сочувствую, но это не значит, что все тесты такие

И моё объяснение этому факту просто - сделать не говнотесты как правило в разы сложнее, чем решить саму задачу, которую эти тесты должны тестировать.

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

> Там описание какого-то культа.

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

Папуасам обещают, что если они будут поклоняться этому богу, их код будет работать.

можно, TDD именно про это, но не надо говорить, что надо отключать моск

Тут есть тонкость: а достаточное ли TDD средство для проектирования? Я для себя ответил - однозначно нет. То есть нельзя рассматривать TDD как самодостаточную методологию. Вот написание тестов как заключительную стадию проектирования можно. А что должно быть «до» - TDD умалчивает.

кто мешает написать прототип?

Никто не мешает, использую. И это как раз аргумент в пользу скудности TDD. Совершенно необходимо чем-то заполнить брешь проектирования. Я смотрю сейчас на TDD+FDD.

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

И туевой хучи времени на реализацию. Ма-а-а-аленький такой пустячок.

Ведь дьявол то на самом деле не в 2+2, а в интеграции.

дьявол в деталях, так что и в 2+2 тоже, и чаще там, чем где-либо ещё, ибо, кажется, что уж в 2+2 ошибки быть не может и соответственно это 2+2 смотрится не так тщательно, со всеми вытекающими

А полноценные инеграционные тесты - это будет 1) полный звиздец 2) замена тестировщиков.

почему звездец-то?

у тестировщиков своя задача, у интеграционных тестов - своя

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

часто бывает так что программную систему невозможно окинуть взглдяом, а ещё чаще так бывает что нет нижележащего/вышележащего кода, а есть только либа, которую ты разрабатываешь

> зачем же тогда всё это тестирование придумали?

А с какой целью интересуетесь? Там у беседы есть предыстория, можно посмотреть её, если что.

Вы путаете модульные и приёмочные тесты,

Пруфы?

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

Это, типа, был аргумент? Не, ну если альтернатива дебаггеру, то тесты конечно лучше...

Это типичная методологическая ошибка.

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

>можно, TDD именно про это, но не надо говорить, что надо отключать моск

Тут есть тонкость: а достаточное ли TDD средство для проектирования? Я для себя ответил - однозначно нет.

конечно - нет

А что должно быть «до» - TDD умалчивает.

а это и не его задача, в общем то

И это как раз аргумент в пользу скудности TDD.

просто TDD - это не панацея, у него есть своя область определения, это скорее инструмент для микропроектирования, нежели что другое, например, TDD удобно использовать для проектирования API - сразу оцениваешь как будут с твоим кодом работать другие люди

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

И туевой хучи времени на реализацию.

это заблуждение, которое часто возникает из непонимания сути TDD

давайте посмотрим, опишите как Вы обычно пишете код (можно без особых деталей)

> Вы путаете модульные и приёмочные тесты,

Пруфы?

да вот они, в предыдущем сообщении Вы написали:

проверкой корректности приложения

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

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

и да, в итоге модульные тесты помогают в деле оценки корректности работы приложения, но лишь как дополнение, а не основной инструмент

Не, ну если альтернатива дебаггеру, то тесты конечно лучше...

простите, а Вы как пишете код, не поделитесь?

> зачем же тогда всё это тестирование придумали?

А с какой целью интересуетесь?

хочу понять Вашу точку зрения

Там у беседы есть предыстория, можно посмотреть её, если что.

я её внимательно прочитал

Так то оно все так, но TDD пропагандируется как нечто самодостаточное, вот это зло.

Кстати, вот насчет «использовать для проектирования API» - для этого не нужен полноценный набор тестов, достаточно пару типичных примеров использования набросать. Я обычно делаю так: пишу клиентский код будто у меня уже есть api моей мечты. И это даже не тест, просто наброски, которые я сохраняю в текстовый файл.

>> А полноценные инеграционные тесты - это будет 1) полный звиздец 2) замена тестировщиков.

почему звездец-то?

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

часто бывает так что программную систему невозможно окинуть взглдяом, а ещё чаще так бывает что нет нижележащего/вышележащего кода, а есть только либа, которую ты разрабатываешь

И как это мешает разрабатывать модули для линуксового ядра, к примеру? Этот факт не может и не должен рассматриваться как оправдание шаманизму. А вера в «TDD гарантирует» - это именно оно и есть.

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

Ну вот давай без теории, давай ЖЖ. Как часто тесты показывали тебе ошибки?

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

> Если тесты пройдены - код верифицирован.

Нет. Нет! НЕТ, БЛЯДЬ !!!!

Код верифицирован тогда и только тогда, когда для каждого пути выполнения доказано соблюдение инвариантов. Вот это - верификация.

Если ты хочешь верифицировать код тестами, тебе придется сначала верифицировать сами тесты.

Вот это реально зло тестодрочерства - то, что программисты не знают, что такое верификация.

>>> Вы путаете модульные и приёмочные тесты,

Пруфы?

да вот они, в предыдущем сообщении Вы написали:

Цитата

проверкой корректности приложения

это не задача для модульных тестов,

А где шла речь о «модулях»? Я этого не вижу, пруфы, пожалуйста.

Так то оно все так, но TDD пропагандируется как нечто самодостаточное, вот это зло.

тут полностью согласен, любые перегибы - это не здорово

Кстати, вот насчет «использовать для проектирования API» - для этого не нужен полноценный набор тестов, достаточно пару типичных примеров использования набросать. Я обычно делаю так: пишу клиентский код будто у меня уже есть api моей мечты. И это даже не тест, просто наброски, которые я сохраняю в текстовый файл.

модульные тесты позволяют поставить API под контроль, и не только тесты, но и поведение

> простите, а Вы как пишете код, не поделитесь?

«По старинке» - формулирование требований, декомпозиция задачи и так далее. Ничего революционно нового. Я ретроград.

Как часто тесты показывали тебе ошибки?

Давайте сделаем так, как уже сделали все умные люди: s/тесты/спеки/

Проделайте мысленно эту нехитрую процедуру и попробуйте сами ответить на вопрос «как спеки показывают ошибки».

они не сказли мне о моём коде больше того, что я о нём уже знал.

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

у реального продукта бесконечное множество вариантов использования

это ещё доказать надо

но и без доказательства я Вам скажу что Вы не правы, ибо количество фич продутка - есть счётное множество (иначе написать ни один продукт за конечное время не удалось бы), а варианты использования - это все возможные сочетания использования фич -> конечное число

>>> зачем же тогда всё это тестирование придумали?

А с какой целью интересуетесь?

хочу понять Вашу точку зрения

Я уже изложил её: http://www.linux.org.ru/jump-message.jsp?msgid=6399536&cid=6400305

Там у беседы есть предыстория, можно посмотреть её, если что.

я её внимательно прочитал

Тогда почему потеряли контекст? Мой риторический вопрос имеет смысл только в том контексте.

> часто бывает так что программную систему невозможно окинуть взглдяом, а ещё чаще так бывает что нет нижележащего/вышележащего кода, а есть только либа, которую ты разрабатываешь

И как это мешает разрабатывать модули для линуксового ядра, к примеру?

а должно? :)

Этот факт не может и не должен рассматриваться как оправдание шаманизму.

при чём тут шаманизм? Вы сказали что единственная причина, которую Вы можете назвать, для применения TDD - непонимание нижележащего кода, я Вам привёл пример когда Вы пишете код с использванием тестирвоания сейчас, но нет ещё нижележащего/вышележащего кода - Ваш аргумент ушёл со свистом по трубе, смытый набежавшей водой

Код верифицирован тогда и только тогда, когда для каждого пути выполнения доказано соблюдение инвариантов. Вот это - верификация.

Это формальная верификация. Просто более строгая. Тесты - это облегченная ее версия. Вообще формальные методы используют для автоматической генерации тестов.

Если ты хочешь верифицировать код тестами, тебе придется сначала верифицировать сами тесты.

Если хочешь на все 100% верифицировать, то да. А если мне достаточно, скажем, на 95%, то мне и этого хватит.

>>Как часто тесты показывали тебе ошибки?

Давайте сделаем так, как уже сделали все умные люди: s/тесты/спеки/

Не получается. К примеру, тривиальная «спека» - «возможность добавить в базу данных 'большое' количество записей о клиентах». Никак не получается заменить на тесты. Ну никак.

они не сказли мне о моём коде больше того, что я о нём уже знал.

Они и не должны.

Повторюсь, а нахера они тогда нужны?

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

И снова повторюсь - это НЕ доказательство. Докозательство - это формальная процедура. И да, я делаю её для сложных участков кода. Вместо написания тестов.

я не против тестов, они очень часто не заменимы хотя бы просто для оценки производительности

тестирование производительности может в себя включать нагрузочное тестирование, стресс-тестирование и тестирование стабильности, и это всего лишь один из видов тестирования

Но перекладывать на тесты «безошибочность работы» - это попрание законов логики в чистом виде.

не перекладывать, а использовать как подстраховку

Ну вот давай без теории, давай ЖЖ. Как часто тесты показывали тебе ошибки?

тесты не «показывают» ошибки, они позволяют их не допускать, серьёзно

а ещё тесты дают определённую уверенность в том что написанный код работает как надо, даже после рефакторинга