Какой лучший аргумент, чтобы убедить разработчиков изучать TDD?

Question

Позвольте мне сначала выйти из шкафа. Я сторонник TDD. Я стараюсь практиковать тестовую разработку как можно больше.

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

• Почему? До сих пор я был довольно успешным разработчиком.
• Это замедлит меня.

Какой лучший аргумент про TDD слышал или использовал?

---

См. Также: Какая лучшая причина для модульного тестирования?

Answer 1

Возможно, они знают лучше.

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

При этом, TDD не волшебная пыльца пикси:

1. подход «просто напишите достаточно кода, чтобы пройти тест» дает ложные срабатывания. Часто известны заблуждения и проблемы, которые подход «достаточно» не решает. В качестве примера можно привести ошибки распределенных систем или проблемы с производительностью NUMA. Простое включение этих требований в выражение этих тестов для TDD само по себе превращается в работу на полный рабочий день.
2. взрыв moq выходит из-под контроля для любого серьезного проекта. mocks - это код, как и любой другой код, его нужно поддерживать и просто не писать самому себе.
3. TDD часто используется в качестве предлога для устранения контроля качества. «наш разработчик уже написал проверенный идентификатор, давайте отправим его» полностью игнорирует сквозное тестирование, ориентированное на функциональные возможности, которое должно охватывать
4. Я не доверяю лисе, охраняющей курятник. Алгоритм неправильный все еще может передавать TDD с плавающими цветами, если в тесте и в реализации были допущены одинаковые ошибки.
5. В конце концов, все методологии пытаются использовать процесс для замены таланта.

Моя главная ссора с TDD заключается в том, что она представляет собой волшебное решение большинства проблем разработки, но его сторонники скрывают ее стоимость. Удвоение или утроение вашей кодовой базы с помощью moqs не бесплатно. Я предпочитаю увидеть несколько комплексных модульных тестов, написанных во время разработки. Первый подход к тестированию TDD, я пока не вижу его преимуществ в реальном проекте.

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

Answer 2

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

Вы должны ПОКАЗАТЬ их и продемонстрировать преимущества. Легче заставить кого-то «светиться», показывая, а не рассказывая.

Answer 3

TDD - это компромисс «плати мне сейчас или плати позже». Если вы только отсчитываете время от начала кодирования до проверки в своем коде, то TDD часто занимает больше времени, особенно при первом изучении TDD. Окупаемость наступает позже на этапе тестирования, а также в будущих циклах кодирования.

Для фазы тестирования я обнаружил, что с TDD:

1. У меня было значительно меньше ошибок. В моем последнем коде TDD у меня были ошибки только из-за недопонимания требований (или изменений) или из-за областей, в которых я не смог принести тестируемый код (в данном случае PHP-код).
2. Ошибки, которые у меня были, как правило, было легче воспроизвести при тестировании, потому что я уже получил тестируемую систему.
3. Исправление ошибок происходило быстрее, и с помощью тестов я мог поверить, что я не представил новых ошибок.

Сам код имел следующие свойства:

1. Когда я начал думать, как клиент кода, код, как правило, был проще в использовании. (Это одно из преимуществ написания тестов первым.)

2. Код легче проверить.

3. Написание модульных тестов проще (и во многих случаях веселее) как раз перед, а не после, поэтому пишется больше тестов.

4. Код легче реорганизовать и очистить. Это было особенно верно для Python, где инструментам автоматического рефакторинга приходится труднее.

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

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

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

Answer 4

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

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

Answer 5

Разные люди будут убеждены (или нет) по-разному, поэтому единственный честный ответ - «это зависит».

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

Answer 6

Для меня моментом «ага» было чтение главы 2 «Разработка через тестирование в Microsoft.Net» Джеймса Ньюкирка. (Не то, чтобы остальная часть книги не была важной ... он посвящает несколько глав созданию многоуровневого приложения в TDD).

Он создает простой стек, но вы видите, что код «развивает» его сложность, а не начинает сложный.

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

Answer 7

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

Answer 8

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

Таким образом, я не думаю, что вы сможете убедить любого, кто предъявляет эти требования, своими собственными рациональными аргументами. Лучшим способом будет обратиться к источнику своих аргументов; опыт. Либо заставьте их временно использовать TDD, чтобы посмотреть, что они об этом думают, либо же TDD поработают сами, что явно очень хорошо, и представьте их в качестве примера.

(Я не сторонник TDD. Это практичный способ убедить меня, что это хорошая идея.)

Answer 9

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

Answer 10

Покажите им эту презентацию. Это продало меня.

http://www.slideshare.net/sebastian_bergmann/testing-with-phpunit-and-selenium-156187

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