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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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