Опробовать разработку через тестирование

Question

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

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

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

• Вы также верите, что TDD действительно помогает GTD?
• Что мне нужно знать о TDD?
• А как насчет альтернатив TDD?
• Какая методология лучше всего подходит для организации / разработки веб-приложения TDD?
• Какие библиотеки мне следует использовать (если есть), чтобы облегчить мою жизнь?

PS: я в основном (но не исключительно) работаю с PHP здесь.

Answer 1

Лично я считаю, что TDD в лучшем случае излишне, а в худшем - препятствует творческому процессу программирования. Время, потраченное на кропотливое написание модульных тестов для каждого еще не написанного метода / класса, было бы лучше потрачено на решение исходной проблемы. При этом я большой поклонник юнит-тестов и искренне верю в них. Если у меня есть особенно сложный или проблемный фрагмент кода, я с радостью напишу 20 модульных тестов для одного метода, но в общем случае ПОСЛЕ того, как я решил проблему. TDD, как и любая другая парадигма программирования, не является серебряной пулей. Если это подходит, вы используете его, если не продолжать искать.

Но прими мое мнение с крошкой соли. Гораздо более интересным является Кент Бек и Насколько глубоки ваши юнит-тесты? .

Answer 2

Я недавно начал использовать «тонкие контроллеры толстых моделей» http://www.amitshah.in/php/controller-vs-model.html: выталкивать как можно больше кода в модель (и из вида / контроллера).

Я использую PHPUnit (и поддержку Zend Framework для него), чтобы протестировать только несколько сложных моделей в моих веб-приложениях. Написание модульных тестов, которые тщательно проверяют двухстрочную функцию, которая выполняет простой запрос SQL, - это пустая трата времени, IMHO. За последние пару лет я стал ленивее и ленивее в написании тестов, и для большинства веб-приложений это не стоит того, потому что код такой простой.

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

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

Answer 3

Вы также верите, что TDD действительно помогает GTD? Моя самая большая проблема была просто неспособность проверить код. Это было слишком сложно. Наши основные библиотеки не были построены вокруг легко тестируемого интерфейса. Итак, мы написали тесты для всего, что могли. В итоге мы закончили рефакторинг наших основных библиотек, чтобы облегчить жизнь. Кроме того, это изменение мышления, и я бы определенно рассмотрел вопрос о том, чтобы уделить больше времени вашему первому проекту TDD, просто чтобы устранить некоторые проблемы, которые могут возникнуть на этом пути.

Что мне нужно знать о TDD? TDD не является заменой методологии. Это выгодное дополнение или, по крайней мере, так должно быть. Если все сделано правильно, TDD значительно улучшает дизайн программного обеспечения. Это также действует как ваша внутренняя документация. Если вы хотите, чтобы кто-то посмотрел на ваш API и понял, как он работает, он может просто посмотреть на ваши хорошо названные сформированные тесты.

А как насчет альтернатив TDD? Как я уже сказал, я не считаю это заменой методологии. Существует альтернатива, и это не использовать его:)

Какая методология лучше всего подходит для организации / разработки веб-приложения TDD? Мы были довольно успешны с Scrum / Agile, если это то, что вы спрашиваете.

Какие библиотеки мне следует использовать (если есть), чтобы облегчить мою жизнь? Мои знания PHP истекли 5 лет назад, и я позволю кому-то другому ответить на этот вопрос.

В любом случае, только мои 2 цента. Если вы чувствуете, что читаете здесь, хороший обзор: http://www.agiledata.org/essays/tdd.html