Почему разработка, управляемая тестами, отсутствует в тесте Джоэла?

23

Я читал этот блог Джоэла Спольски о 12 шагах по улучшению кода . Отсутствие Test Driven Development действительно удивило меня. Поэтому я хочу передать вопрос Гуру. Разве TDD не стоит усилий?

Фанат
источник
13
Эта статья была написана в среду, 9 августа 2000 года (около 12 лет назад). Не то чтобы TDD не было в то время, но я не верю, что он наслаждался почти таким же шумом, как сейчас.
Майк
12
Тест Джоэла - это просто набор общих рекомендаций. Не все, что «стоит усилий», может туда поместиться.
Яннис
2
« Я придумал свой собственный, крайне безответственный, неаккуратный тест, чтобы оценить качество команды разработчиков программного обеспечения. Самое замечательное в этом то, что это занимает около 3 минут ... Отличная вещь в тесте Джоэла состоит в том, что легко быстро получить ответ «да» или «нет» на каждый вопрос. Вам не нужно вычислять количество строк кода в день или среднюю ошибку в пересчете на точку ... » - решение о том, принесет ли ваш проект пользу от TDD, займет более 3 минут, и, что ж, , может потребоваться определить среднюю ошибку на точку перегиба - вот почему его нет в списке
комнат
Перейдите к Джоэлу Стеку, плз. Это интересный вопрос.
Эрик Реппен
Вы должны принять ответ, который ссылается и цитирует непосредственно от Джоэла, поскольку он не становится более авторитетным, чем этот. См. Programmers.stackexchange.com/a/189493/6586
Брайан Оукли

Ответы:

30

Разработка, основанная на тестировании, была практически неизвестна до выхода книги Кента Бека в 2002 году, через два года после того, как Джоэл написал этот пост. Тогда возникает вопрос, почему Джоэл не обновил свой тест, или если бы TDD был более известен в 2000 году, включил бы он его в свои критерии?

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

Карл Билефельдт
источник
1
Кроме того ... о, ты в некотором смысле попал в TDD, это пункт помощи Kool, не так ли?
Эрик Реппен
27

Джоэл на самом деле обращался к этому конкретно в нескольких местах.

Он объяснил, что тесты не способны уловить много важных проблем, особенно субъективных, таких как "пользовательский интерфейс этого программного обеспечения - отстой?" По его словам, чрезмерная зависимость от автоматизированных тестов в Microsoft - это то, как мы закончили с Windows Vista.

Он написал, как, по его опыту, ошибки, которые на самом деле обнаруживают пользователи, делятся на две категории: 1) те, которые обнаруживаются в обычном использовании, которые программисты могли бы найти, если бы они запускали свой собственный код перед его использованием. или 2) крайние случаи настолько неясны, что никто бы и не подумал написать тесты, чтобы покрыть их в первую очередь. Он заявляет, что лишь очень небольшой процент ошибок, которые он и его команда исправляют в FogBugz, - это та вещь, которую поймало бы модульное тестирование. (Я не могу найти эту статью сейчас, но если кто-то знает, какую я имею в виду, не стесняйтесь редактировать ссылку здесь.)

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

Мейсон Уилер
источник
2
На самом деле, вы правы. Обычное МО Джоэла - соломенный человек. Как будто TDD не поймал бы никаких ошибок для меня, так что это не может быть хорошо. Что несколько упускает из виду, что TDD - это не тестирование, а дизайн. Оставленные тесты являются бонусом. Или утверждать, что небольшое изменение сломает многие юнит-тесты, что говорит о том, что он просто делает это неправильно. Или полностью переписать принцип SOLID, прежде чем атаковать его. Такого рода вещи. На самом деле его сторонники используют круговую логику, а не он.
фунтовые
7
Я полностью согласен с этими комментариями Джоэла. Я думаю, что еще более серьезной проблемой является язык - со многими динамическими языками, которые я не могу себе представить, делая что-либо без юнит-тестов, - как еще вы можете сказать, вызовет ли простая опечатка какую-то проблему, которую вы не увидите, пока не появится критическая момент? В статически типизированных, скомпилированных языках, предназначенных для уменьшения ошибок, вы избегаете самых простых ошибок и в основном оставляете за собой логические ошибки. Это уменьшает потребность в типе полного покрытия, предоставляемого TDD.
Билл К
2
@MasonWheeler: Вы серьезно утверждаете, что безопасность компиляторов / типов устраняет необходимость в модульных тестах? Вы также преднамеренно игнорируете преимущества дизайна TDD, но, что более важно, у вас должно быть чертовски много времени на рефакторинг чего-либо. Скорее, обратное было верным: например, разработчики .NET, которые следуют методологии TDD, внезапно оказываются разочарованы количеством кода, которое им нужно написать, чтобы угодить компилятору, который все более бесполезен в ответ.
pdr
2
@pdr: я серьезно утверждаю, что «потребность в модульных тестах» - это прежде всего отсутствие безопасности типов. И, не будучи разработчиком .NET, я не могу много рассказать об их опыте, но по своему опыту я обнаружил, что трудности с рефакторингом основаны исключительно на двух факторах: написал ли я код в первом место, и хорошо ли автор написал код. (Примечание: пункты 1 и 2 не обязательно сильно связаны друг с другом!)
Мейсон Уилер
3
Модульные тесты @Pdr не подтверждают ваш код, они в основном проверяют синтаксис, но могут быть очень полезны при разработке. Интеграция и системные тесты имеют гораздо больше смысла, хотя. Кроме того, большинство рефакторингов в статически типизированных языках может быть доказано безопасным, фактически это и есть рефакторинг - набор известных «безопасных» операций, которые преобразуют ваш код без внесения изменений. На статическом языке среда IDE может часто вносить эти изменения для вас и гарантировать, что они безопасны, что часто невозможно в динамических языках, которые поэтому требуют модульных тестов, чтобы помочь (а не доказать) ту же безопасность
Bill K
25

Джоэл Спольски сам ответил на этот вопрос еще в 2009 году :

Джоэл: Есть дебаты по поводу разработки, управляемой тестами ... если у вас есть модульные тесты для всего, такого рода вещи ... многие люди пишут мне после прочтения "Теста Джоэля", чтобы сказать: "У вас должен быть 13-й здесь: модульное тестирование, 100% модульные тесты всего вашего кода. "

И мне кажется, что я слишком доктрина о том, что вам может не понадобиться. Мол, вся идея гибкого программирования состоит не в том, чтобы делать что-то до того, как они вам понадобятся, а в том, чтобы при необходимости исправлять ошибки. Я чувствую, что автоматическое тестирование всего, много раз, просто не поможет вам. Другими словами, вы собираетесь написать очень много модульных тестов, чтобы гарантировать, что код действительно будет работать, и вы определенно узнаете, не работает ли он [если вы этого не сделаете писать тесты] делает, на самом деле все еще работает, ... я не знаю, я получу такую ​​пламенную почту для этого, потому что я не выражаю это так хорошо. Но я чувствую, что если бы команда действительно имела 100-процентное покрытие кода своих модульных тестов, возникла бы пара проблем. Один, они потратили бы очень много времени на написание модульных тестов, и они не обязательно могли бы платить за это время с улучшенным качеством. Я имею в виду, что у них было бы улучшенное качество, и они могли бы изменить вещи в своем коде с уверенностью, что они ничего не сломают, но это все.

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

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

Росс Паттерсон
источник
2
В самом деле? Понижает голосование при публикации собственного ответа Джоэла на вопрос ОП?
Росс Паттерсон
1
Трудно понять. Некоторые люди используют голос, чтобы означать «я одобряю», а не «это полезно». Это, очевидно, должен быть принятый ответ, потому что он является окончательным.
Брайан Оукли
Я никогда не работал над проектом, в котором было 100% тестовое покрытие. Но если у вас 0% тестового покрытия ... ... это очень показательно.
Kzqai
Спасибо! Я думаю, что это должно быть помечено как принятый ответ.
Джалал
5

Никто, кроме Джоэла, не мог ответить на это наверняка. Но мы можем попробовать некоторые причины / наблюдения.

Прежде всего, тестирование не отсутствует в тесте Джоэла

  • Тесты упоминаются два раза в 12 шагов напрямую (10 и 12)
  • Существование билда является одним из первых пунктов. Идея сборки заключается в том, чтобы получить возможность увидеть, не сломались ли они, поэтому мы (также) говорим о тестировании здесь.

Во-вторых, вся идея теста Джоэла (насколько я понимаю) состоит в том, чтобы иметь быстрые вопросы, да-нет. "Ты делаешь TDD?" не совсем подходит (ответ может быть: «некоторые из нас», «для этой части кода» или «мы проводим модульный тест»).

В-третьих, я думаю, что никто не сказал, что (даже Джоэл), что те моменты, когда «единственное стоит времени» (кстати, «ты программируешь», не на нем), просто, что это хорошие быстрые вопросы, которые нужно задать, когда придет в контакте с командой разработчиков программного обеспечения, будь то будущий член команды или даже клиент, - вот список, который я дал некоторым нетехническим людям вокруг меня, которые искали подсказки о том, насколько хорош / плох их собственный ИТ-отдел. Это не все, но это действительно плохо бить за три минуты.

Мартин
источник
3
"Ты делаешь TDD?" конечно подходит как вопрос да-нет. И под этим я подразумеваю, что на этот вопрос все отвечают решительным «да», что на самом деле означает «нет».
Яннис
2
@YannisRizos: Во многом как "Вы используете лучшие инструменты, которые можно купить за деньги?" (Да ... хорошо ... в пределах разумного.) И "У программистов тихие условия работы?" (Ооооооооооооооооооочитать, что от вас зависит спокойствие, я думаю.)
pdr
@pdr Зависит от того, считаете ли вы тихим звук сирен, проникающих через открытые окна.
Роберт Харви
Также «Да, я занимаюсь дизайном сверху вниз ». ;)
Изката