Ruby on Rails c нуля!

Практикуйте BDD, не будьте похожи на подавляющее большинство PHP программистов

Почему это?!

BDD позволяет хорошо продумать архитектуру вашего приложения, продумать, как будет реализован функционал, отсечь лишний функционал и заранее подготовить тесты.

Ранее я только игрался со спецификациями BDD и использовать их в реальной работе не желал. Я изучил поверхностно работу с RSpec просто потому, что «Rspec необходимо знать», а это убеждения возникло у меня из-за частого упоминания RSpec в вакансиях на различных сайтах — агрегаторах вакансий Ruby/Rails программистов. На практике, до недавнего времени я избегал использования RSpec и мне казалось, что очень ловкое шимпанзе, которое успешно избегает всех этих заморочек со спецификациями. Мне казалось, что работая в одиночку можно спокойно обойтись без BDD, и что BDD только забирает время, которое можно потратить на написание кода самого приложения, а не бесполезных с функциональной точки зрения спецификаций. Чуть позже я нашел работу Rails программиста в одной компании, где спецификации также не пишут, а работа по тестирования взгромождена на широкие плечи титанов — тестировщиков. Здесь мне тоже удалось успешно избежать необходимости писать спецификации.

Когда же я начал работать над Quasar CMS то уже было некоторое чувство внутри, что я делаю что-то не так, что нужно все хорошо продумать, но привычка делать, а потом думать привела к тому, что спецификациями покрыто не более 2% кода Quasar CMS и потому я решил заняться написанием спеков ко всему коду, что будет готов на момент 31 мая — так я решил отпраздновать свой день рождения. Это не совсем правильно покрывать спеками уже написанный код, но это лучше, чем когда их совсем нет.

Помимо Quasar CMS я начал еще один свой сверхсекретный мега стартап, который должен сделать меня миллиардером, ну или хотя бы мультимиллионером, а в худшем случае, я просто еще раз повторю имена методов в Rails и, возможно, познакомлюсь с парочкой новых симпатичных Gem’ов. Этот новый супер стартап я начал как раз со спецификаций.

Честно сказать писать спецификации трудно. Трудно не потому, что спецификации — это что-то сложное, а потому, что необходимо много думать, по 7 раз все отмерять и только по разу все отрезать. Кроме того, поскольку опыта в написании BDD спецификаций у меня крайне мало, возникает множество моментов, когда необходимо заглянуть в документацию, StackOverflow или пробежаться по блогам из закладок с метками «RSpec, BDD, …». Разумеется такие упражнения в google-fu приносят свои плоды и откладывают в мозг крупицы знания и понимания сути BDD и его инструментария. Ссылаясь на свой гипертрофированный коэффициент лени и темпы с которыми я осваиваю BDD могу сказать, что на то, чтобы освоить BDD практики и инструментарий в объеме достаточном для автономной работы, то есть без использования Goggle каждые 5 минут, необходимо потратить времени ок. месяца.

О чем это я? Ах да, BDD — это сложно, но это сложно должно превратиться в легко через 1-2 месяца вашего изучения предмета. BDD — это практики, которые действительно необходимы. Поверьте мне как примату, который долго сопротивлялся необходимости использования BDD в работе.

P.S. У PHP разработчиков действительно туго с тестами и спецификациями. В подтверждение тому можете поискать на Хабре соотв. опрос о том, кто использует BDD/TDD.