Испытание Разработки через тестирование
Мой опыт ограничен (ii) (i) не очень и (ii) пролог; но я могу безопасно сказать, что механизм правила может помочь Вам выразить пропозициональные понятия, намного более чистые, чем процессуальный кодекс.
3 ответа
Лично я считаю, что TDD в лучшем случае является излишним, а в худшем - препятствием для творческого процесса программирования. Время, потраченное на кропотливое написание модульных тестов для каждого еще не написанного метода / класса, лучше потратить на решение исходной проблемы. При этом я большой поклонник модульных тестов и искренне верю в них. Если у меня есть особенно сложный или проблемный фрагмент кода, я более чем счастлив написать 20 модульных тестов для одного метода, но обычно ПОСЛЕ того, как я решил проблему. TDD, как и любая другая парадигма программирования, не является серебряной пулей. Если он подходит, воспользуйтесь им, если не продолжайте искать.
Но отнеситесь к моему мнению с долей скептицизма. Гораздо более интересный пример исходит от Кента Бека и Насколько глубоки ваши модульные тесты? .
Вы тоже верите, что TDD действительно помогает GTD? Больше всего меня беспокоило то, что я просто не мог проверить код. Это было слишком сложно. Наши основные библиотеки не были построены вокруг легко тестируемого интерфейса. Итак, мы написали тесты на все, что могли. В конце концов, мы провели рефакторинг наших основных библиотек, чтобы облегчить жизнь. Кроме того, это изменение мышления, и я определенно подумал бы о том, чтобы выделить больше времени на ваш первый проект TDD, просто чтобы как бы избавиться от некоторых проблем, которые могут возникнуть на этом пути.
Что мне нужно знать о TDD? TDD не заменяет методологию. Это полезное дополнение, по крайней мере, так должно быть. Если все сделано правильно, TDD значительно улучшает дизайн программного обеспечения. Он также действует как ваша внутренняя документация. Если вы хотите, чтобы кто-то посмотрел на ваш API и понял, как он работает, они могут просто взглянуть на ваши хорошо названные сформированные тесты.
А как насчет альтернатив TDD? Как я уже сказал, я бы не стал рассматривать это как замену методологии. Есть альтернатива, и это не использовать ее :)
Какая будет лучшая методология для организации / разработки веб-приложения TDD? Если вы об этом спрашиваете, мы добились довольно больших успехов в использовании scrum / agile.
Какие библиотеки мне следует использовать (если они есть), чтобы облегчить себе жизнь? Мои знания PHP истекли 5 лет назад, и я позволю кому-нибудь ответить на этот вопрос.
В любом случае, только мои 2 цента. Если вы хотите прочитать, вот хороший обзор: http://www.agiledata.org/essays/tdd.html
Недавно я начал использовать «толстые модели тонких контроллеров» http://www.amitshah.in/php/controller-vs-model.html : лопатой как как можно больше кода в модель (и вне представления / контроллера).
Я использую PHPUnit (и его поддержку Zend Framework) для тестирования только нескольких сложных моделей в своих веб-приложениях. Написание модульных тестов, которые полностью проверяют двухстрочную функцию, выполняющую простой SQL-запрос, является пустой тратой времени, IMHO. За последние пару лет я стал все ленивее писать тесты, и для большинства веб-приложений это того не стоит, потому что код такой простой.
Но в недавнем проекте (сайт электронной коммерции, который отслеживает уровни запасов на нескольких складах с составными продуктами) я начал проводить тестовую разработку, потому что знал, что будет много тонких сложностей, которые я не смогу удержать. моя голова сразу. Единственный способ сохранить все работоспособность в соответствии с моим мышлением - это написать несколько тестов. С некоторыми частями казалось более естественным писать класс, чем тесты, другие части сначала тестировались, а другие части не нуждались в тестах, потому что они были тривиальными. TDD - это инструмент, а не религия. Используйте его, когда он работает, остановитесь, если он не работает.
Я вижу преимущество TDD в уменьшении сложности и увеличении скорости (скорости, с которой я могу решать проблемы). Если я напишу несколько тестов, подтверждающих, что мой код работает, то, как только все тесты пройдут, Я могу перейти к следующей проблеме. Это возвращает мне удовольствие от кодирования.