Как бы вы создали блог с использованием TDD-подхода?
Я рассматриваю возможность переделать свой блог (в настоящее время на PHP, но 100 строк кода без макета) в Ruby on Rails только для удовольствия. Я хочу сделать еще один проект в Rails, но я должен изучить Rails (больше, чем привет мир), прежде чем я попытаюсь создать полный проект.
Еще одна вещь, которую я хочу сделать, переделывая свой блог, - это по крайней мере выяснить, что такое TDD. Итак, как бы вы взяли подход Test Driven к созданию блога? Какие тесты вы бы написали? Как бы вы начали?
Каждый раз, когда я визуализую запись в блоге, ему нужно было бы миллион тестов для того, чтобы один компонент мог полностью протестировать его. Как мне избежать написания слишком большого количества тестов?
Кроме того, я делаю это сообщество wiki, потому что я намерен для этого в основном сделать мини-учебник/базу знаний...
Я пошел вперед и поставил щедрость на этот вопрос, так что, возможно, я действительно смогу получить хороший ответ на этот вопрос.
Ответы
Ответ 1
TDD - это больше о дизайне, чем о тестировании. Многие пропустили это и в конечном итоге будут практиковать то, что не совсем похоже на TDD. С TDD вы пишете тест, чтобы изменить код. Вам не нужно беспокоиться о том, чтобы писать слишком много тестов, потому что у вас должен быть только тест для написания, если есть более производственный код для записи (и, следовательно, больше кода для тестирования). Опять же, TDD НЕ о том, чтобы просто написать много тестов для вашего кода, но вы получите множество тестов, и, следовательно, у вас будет очень мощный набор тестов, чтобы дать вам обратную связь по мере роста и изменения вашего кода.
Вместо того, чтобы говорить о том, как тестировать процесс разработки какой-либо определенной части программного обеспечения, я бы рекомендовал вам прочитать и узнать, как практиковать TDD и выяснить, как вы сказали, о чем все это. Одна хорошая книга для рассмотрения: Растущее объектно-ориентированное программное обеспечение, руководствуясь тестами. В книге используется Java, но это большое реальное приложение для использования TDD для создания довольно сложного программного обеспечения.
Там много для TDD, и я бы порекомендовал действительно копаться в нескольких хороших источниках, если вы хотите учиться и пытаться практиковать это, потому что в ответах на этот вопрос есть больше, чем может быть затронуто.
Ответ 2
Взгляните на заинтересованных сторон и на то, чего они хотят достичь. Важно начать там, потому что это позволяет вам правильно расставить приоритеты (т.е. Не в самой интересной технической части, а со своей самой большой коммерческой стоимостью). Разработчик является заинтересованной стороной, и снижение его опасений (из-за невозможности построить что-то) является действительной целью.
Мысль о дизайне записывается в тестах. Начните с конечных целей заинтересованных сторон, работайте оттуда назад до начала (Time-inversion). Это гарантирует, что вы сосредоточитесь на чем и меньше на том, как. Взаимодействие между объектами более важно, чтобы получить права, чем атрибуты объекта.
Смотрите:
Ответ 3
У меня есть аналогичное мнение Питу, его больше о дизайне.
Прыжки на нее, прежде чем смотреть на информацию о качестве, скорее всего, не дадут вам результатов. Скорее всего, вы просто подумаете: эти тесты испытывают боль. Это осознание того, что есть проблемы с дизайном, но он не скажет вам, как улучшить его.
Вы сказали "в настоящее время на PHP, но 100 строк кода без макета", если в этом случае есть, вероятно, несколько функций. Если вы сосредоточены на фактических необходимых функциях, также должно быть несколько тестов/выше, чем количество функций, но, пока те являются правильными модульными тестами, номер не должен взорваться - проверить это видео.
Ответ 4
Начните с написания функций Cucumber, чтобы обеспечить "внешний доступ". Они должны иметь возможность самостоятельно тестировать большую часть ваших функций. Очень легко писать. В блоге не так много тестов, после всего, что это просто сообщения и комментарии, не так ли? Посмотрите на мое приложение blorgh, которое представляет собой приложение Rails, разработанное с использованием Cucumber.
Ответ 5
Интересно, это именно то, что я начал пару дней назад. Я использую RSpec и Cucumber. Я начал писать пару спецификаций для моделей Article и Comment. Когда все стали зелеными, я написал тесты Cucumber для реализации представлений, контроллеров и т.д.
Это работает очень хорошо для меня, но я думаю, что начиная с Cucumber тоже хорошо, так как многим, похоже, нравится этот подход.
Если у вас мало знаний RSpec и Cucumber, я настоятельно рекомендую Railscasts:
Мне также понравились Peepcode screencasts, но в отличие от railscasts они стоят 9 $каждый.
