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

Question

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

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

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

Спасибо

=> натолкнулся на это сегодня, из блога Джоэла Спольски, одного из основателей stackoverflow:

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

Answer 3

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

Answer 4

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

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

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

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

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

Или, может быть, это действительно работает, но вы этого не понимаете. Одна вещь в работе соло состоит в том, что самооценка сложна .

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

Answer 5

Я обнаружил, что люди слишком много внимания уделяют ТЕСТУ в TDD. Многие не верят, что именно это имели в виду создатели.

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

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

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

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

• Что в истории
• Представляем BDD
• Проектирование военных кораблей клингонов с использованием управляемой поведением разработки

Answer 6

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

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

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

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

Кроме того, разработка, основанная на тестировании, до некоторой степени забавна.

Answer 7

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

• Вы проверяете код, чтобы вывести ошибки

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

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

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

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