// codeart.ru / Вопрос/Ответ / Оцепенение перед сложностью задачи Форум

Оцепенение перед сложностью задачи rss подписка

Автор: Evgeniy Sergeev

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

Это у тебя оцепенение перед сложностью задачи. Нет необходимости решать задачу целиком. Точнее это совершенно неправильно, что ты пытаешься представить себе конечный тест. Думаешь о том, что тебе нужен будет WordPress и еще какие-то мелочи. И забываешь, что разработка через тест — это итеративный процесс.

Первое, выкинь все из головы и выбери одно из действий, которое я определил в задании.
Второе, сделай то что тебе понятно. Например, ты из задания знаешь какие входные данные должны быть у действия, знаешь как называется действие и по какому урлу оно доступно. Значит запиши это в соответствующий тест.
Третье, ты не знаешь какой конкретно должен быть формат сообщения, которое должно вернуться из контролера? Ну так просто назови его пока что successfully message и укажи, что в качестве результата ты ожидаешь эту строку.
Четвертое, запусти тест и получи красную полосу. Дальше сделай реализацию метода — т.е. просто верни строку suceffuly message и получи работающий тест.

И вот тут первая проблема — простые действия вроде бы закончились — тебе нужно делать реализацию метода, которая бы обращалась к WordPress. А это как бы требует написания теста, который должен в итоге дать зеленую полосу. И скорее всего эта мысль стопорит, так как неясно в какой форме будет получен результат от WordPress. И здесь главное понять, что разработка идет через красную полосу — т.е. надо сначало получить неработающий тест. В нашем случае для красного теста достаточно сделать реализацию, которая будет возвращать нечто отличное от successful message. Ну и отлично! Оставляем тест в покое и делаем реализацию: поставить WordPress, установить гем для xmlrpc, посмотреть примеры использования гема и сделать простейший запрос к WordPress, который может даже не использовать данные, получаемые на вход. Просто какой-то зарос, который позволит получить информацию о структуре сообщения, получаемого от WordPress. Когда мы сделаем эту реализацию, то получим красную полосу и информацию о том, что тест ожидал одни данные, а получил другие. Тогда мы просто изменим ожидание теста, так чтобы появилась зеленая полоса. И тут важно понимать, что когда мы подгоняем результат теста, то фактически в этот момент мы как бы говорим, что данные полученные от WordPress правильные, если в этот момент ты ошибешься то тест будет врать.

Дальше продолжаем допиливать реализацию, получая красную полосу и корректируя результат теста.

Здесь еще можно сказать об одной мысли. Вообще tdd требует чтобы мы реализацию делали по тесту, а не подгоняли тест под результат. Но если вдуматься, то у нас так и есть, изначально мы указали, что ожидаем сообщения об успехе, а потом просто уточняем форму этого сообщения, не меняя при этом смысл теста.

И не забудьте: горнолыжные туры в следующие страны: Австрия, Швейцария, Италия, Франция, Андорра, Норвегия, Болгария, Турция.
  1. Приступая к выполнению любой задачи, вариантов решения может быть несколько и не всегда они сразу понятны. Лучше просто делать шаг за шагом и тогда придешь к логическому завершению.

Leave a Reply

« »