Как бы вы сделали блог с подходом TDD?

Question

Я подумываю переделать свой блог (в настоящее время на PHP, но <100 строк кода без макета) в Ruby on Rails, просто для удовольствия. Я хочу сделать еще один проект в Rails, но я должен изучить Rails (больше, чем hello world), прежде чем я попытаюсь создать полный проект. </p>

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

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

Кроме того, я делаю это сообщество вики, потому что я намерен сделать его в основном мини-учебником / базой знаний ...

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

Answer 1

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

Вместо того, чтобы говорить о том, как протестировать разработку некоторого конкретного программного обеспечения, я бы порекомендовал вам прочитать и научиться практиковать TDD и выяснить, как вы сказали, в чем суть. Одна хорошая книга для рассмотрения: Растущее объектно-ориентированное программное обеспечение, управляемое тестами . Книга использует Java, но это отличное приложение с использованием TDD для создания довольно сложного программного обеспечения.

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

Answer 2

У меня такое же мнение, как и у Пита, оно больше касается дизайна.

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

Вы сказали «в настоящее время на PHP, но <100 строк кода без макета», если это так, вероятно, есть несколько функций. Если вы сконцентрируетесь на реальных нужных функциях, то, конечно, также должно быть несколько тестов / больше, чем количество функций, но если это правильные юнит-тесты, число не должно взорваться - <a href="http://www.infoq.com/presentations/integration-tests-scam" rel="nofollow noreferrer"> проверьте это видео,

Answer 3

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

Мнение о дизайне записано в тестах.Начните с конечных целей заинтересованных сторон, оттуда работайте задом наперед к началу (Инверсия времени).Это гарантирует, что вы концентрируетесь на чем, и меньше на том, как.Взаимодействие между объектами важнее для получения прав, чем для атрибутов объекта.

См .:

• http://www.robvens.nl/en/articles/computers/29-time-inversion-pattern
• http://www.robvens.nl/en/articles/computers/28-active-passive-pattern

Answer 4

Интересно, это именно то, что я начал пару дней назад.Я использую RSpec и огурец .Я начал с того, что написал пару спецификаций для моделей Article и Comment.Когда они все стали зелеными, я написал тесты Cucumber для реализации представлений, контроллеров и т. Д.

Это работает очень хорошо для меня, но я думаю, начинать с Cucumber тоже хорошо, так как многим этот подход нравится.* Если у вас мало знаний о RSpec и Cucumber, я настоятельно рекомендую Railscasts :

• Начиная с огурца
• Подробнее о огурце
• Тестирование контроллеров с RSpec
• RSpec Matchers & Macros

Мне также понравилось Peepcode скринкасты, но в отличие от Railscasts они стоят 9 $ каждый.

Answer 5

Начните с написания функций Cucumber, чтобы обеспечить "внешнее" покрытие. Они должны быть в состоянии самостоятельно протестировать большинство ваших функций. Очень легко написать. В блоге не так много тестов, ведь это просто посты и комментарии, верно? Взгляните на мое blorgh приложение, которое является приложением Rails, разработанным с использованием Cucumber.