Каким образом Test Driven Design помогает проекту для одного человека?

Question

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

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

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

Благодаря

=> натыкался этом сегодня, из блога Joel Спольски, один из основателей StackOverflow:.

http://www.joelonsoftware.com/items/2009/09/23.html

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

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

Answer 1

rebugging всегда само собой - просто не удалить ошибки в первую очередь ...

Для реального ответа, вы не можете сделать лучше, чем «это зависит». Если:

• Вы не склонны иметь вид проблем, автоматизированные модульное тестирование может находка (в отличие от производительности, визуальный или эстетических)
• у вас есть какой-то другой способ проектирования код (например, UML)
• вы не склонны иметь дело, чтобы изменить положение вещей, сохраняя при этом они работают

Это вполне может быть так, что TDD действительно не работает для вас.

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

Или, может быть, это действительно работает, но вы этого не осознаёте. Одна вещь о рабочем соло - это self-assessment is difficult.

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

Answer 2

Я думаю, что такая ситуация, как ваша, помогает значительно, когда вам нужно изменить/реорганизовать/оптимизировать что-то, от чего зависит много кода ... Используя модульное тестирование, вы можете быстро обеспечить, чтобы все, что работало до изменение, по-прежнему работает потом :) Другими словами, это дает вам уверенность.

Answer 3

Теоретически размер группы не должен иметь значения. TDD должен окупаться, потому что:

• Вы проверить код, так что вы получите ошибки из

• Когда вы поддерживаете или реорганизовать код, который вы знаете, что вы не разорвать его, потому что вы можете легко проверить это

• вы производите лучший код, потому что вы сосредоточены на крайних случаях, как вы пишете код

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

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

Answer 4

TDD действительно не имеет ничего общего с размером команды. Это связано с созданием минимального объема программного обеспечения, необходимого с правильным интерфейсом, который работает правильно.

Процесс TDD требует, чтобы вы записали только достаточно кода, чтобы удовлетворить тест, поэтому вы не создаете код, который вам не нужен.

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

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

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

Answer 5

TDD - это не только тестирование, но и проектирование ваших классов/API.

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

Answer 6

Еще до того, как термин TDD стал популярным, я всегда писал небольшую основную функцию, чтобы проверить, на какой части я работал. Я сразу выброшу его. Мне трудно понять менталитет программистов, которые могли бы написать код, который никогда не исполнялся, и подключить его. Когда вы обнаружите «ошибку» после этого несколько раз, для отслеживания может потребоваться несколько дней или даже недель.

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

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

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

Плюс, разработка, основанная на испытаниях, до некоторой степени интересна.

Answer 7

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

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

Некоторые люди добираются до создания автоматических модульных тестов. Я использую их как спецификации, так и тестовые примеры. Поскольку они на английском языке, бизнес легко понять их, а также отдел QA.

В общем, это формализованный способ записи спецификаций, чтобы можно было написать код. Разве это не конечная цель?

Вот несколько ссылок

• What's in a Story
• Introducing BDD
• Designing Klingon Warships Using Behaviour Driven Development