Как Вы сделали бы блог с подходом TDD?
Я рассматриваю переделку моего блога (в настоящее время в PHP, но <100 строк кода нерасположения) в Ruby on Rails просто ради удовольствия. Я хочу сделать другой проект в направляющих, но я должен изучить направляющие (больше, чем привет мир), прежде чем я пойду, чтобы попытаться создать полный проект.
Другая вещь, которую я хочу сделать при переделке моего блога, состоит в том, чтобы, по крайней мере, выяснить то, о чем TDD - все. Таким образом, как Вы пошли бы о взятии Теста Управляемый подход к созданию блога? Какие тесты Вы записали бы? Как Вы начали бы?
Каждый раз я визуализирую запись блога, она закончила бы тем, что нуждалась в миллионе тестов для единственного компонента, чтобы полностью протестировать его. Как я стараюсь не писать слишком много тестов?
Кроме того, я делаю эту общественную Wiki, потому что я предназначаю, чтобы это в основном было превращено в мини-учебное руководство/базу знаний...
Я шел вперед и помещал щедрость на этот вопрос поэтому, возможно, я могу на самом деле получить хороший ответ на это..
5 ответов
TDD - это больше о дизайне, чем о тестировании. Многие люди пропускают это и в конечном итоге практикуют что-то, что не совсем похоже на TDD. Используя TDD, вы пишете тест, чтобы внести изменения в свой код. Вам не нужно беспокоиться о написании слишком большого количества тестов, потому что вам нужно написать тест только в том случае, если нужно написать больше производственного кода (и, следовательно, больше кода для тестирования). Опять же, TDD - это НЕ просто написание большого количества тестов для вашего кода, но в конечном итоге вы получите множество тестов и, следовательно, у вас будет очень мощный набор тестов, которые будут давать вам обратную связь по мере роста и изменения вашего кода.
Вместо того, чтобы говорить о том, как тестировать разработку какой-то конкретной части программного обеспечения, я бы рекомендовал вам прочитать и узнать, как практиковать TDD, и выяснить, как вы сказали, в чем все это. Одна хорошая книга, которую стоит рассмотреть: Растущее объектно-ориентированное программное обеспечение, управляемое тестами . В книге используется Java, но это отличное практическое применение TDD для создания довольно сложного программного обеспечения.
TDD - это очень многое, и я бы порекомендовал покопаться в нескольких хороших источниках, если вы хотите изучить и попробовать на практике это, потому что ответов на этот вопрос больше, чем можно поднять.
Начните с написания функций Cucumber, чтобы обеспечить охват «снаружи внутрь». Они должны иметь возможность самостоятельно протестировать большую часть вашей функциональности. Очень легко писать. В блоге не так много тестов, в конце концов, это просто сообщения и комментарии, верно? Взгляните на мое приложение blorgh , которое представляет собой приложение Rails, разработанное с использованием Cucumber.
Интересно, это именно то, что я начал пару дней назад. Я использую RSpec и Cucumber . Я начал с написания нескольких спецификаций для моделей Article и Comment . Когда все они стали зелеными, я написал тесты Cucumber для реализации представлений, контроллеров и т. Д.
Это действительно хорошо работает для меня, но я думаю, что начинать с Cucumber тоже хорошо, так как многим этот подход нравится.
Если у вас мало знаний о RSpec и Cucumber, я настоятельно рекомендую Railscasts :
- Начиная с Cucumber
- Подробнее о Cucumber
- Тестирование контроллеров с помощью RSpec
- RSpec Matchers & Макросы
Мне также понравились скринкасты Peepcode , но в отличие от рейлскастов они стоят 9 долларов каждый.
Взгляните на заинтересованные стороны и на то, чего они хотят достичь. Важно начать именно с этого, потому что это позволяет правильно расставить приоритеты (то есть не в самой интересной технической части, а в той части, которая имеет наибольшую ценность для бизнеса). Разработчик является заинтересованной стороной, и уменьшение его опасений (неспособности что-то построить) - действительная цель.
Размышления о дизайне записываются в тестах. Начните с конечных целей заинтересованных сторон, двигайтесь оттуда в обратном направлении к началу (инверсия времени). Это гарантирует, что вы сконцентрируетесь на том, что, а не на том, как. Взаимодействие между объектами важнее, чем атрибуты объекта.
См .:
У меня такое же мнение, как и у Пита, это больше относится к дизайну.
Прыжок на него, не изучив качественную информацию, скорее всего, не даст вам результатов. Скорее всего, это просто заставит вас задуматься: эти тесты кажутся мучением. Это осознание того, что есть проблемы с дизайном, но оно не скажет вам, как его улучшить.
Вы сказали "в настоящее время на PHP, но <100 строк кода, не связанного с версткой", если это так, то, вероятно, есть горстка функций. Если вы сосредоточитесь на действительно необходимых функциях, то тестов должно быть немного / больше, чем количество функций, конечно, но пока это правильные модульные тесты, их количество не должно взрываться - посмотрите это видео.