Я запускаю приложение Rails для клиента и рассматриваю возможность создания карты разума или прямого перехода к спецификации Cucumber.
Как вы планируете свое приложение Rails?
В качестве дополнительного вопроса, скажем, вы также начинаете с Cucumber, и в этот момент вы будете писать модульные тесты? Перед тем, как выполнить спецификации?
У меня есть шестиэтапный процесс.
Я предпочитаю выработать отношения модели и использовать, прежде чем что-либо делать. Обычно я пытаюсь определить модели в единицах, содержащих когерентные куски информации. Обычно это начинается с определения ортогональных ресурсов, которые потребуются моему приложению (Пользователи, сообщения и т.д.). Затем я выясню, какая информация требуется каждому из этих ресурсов (атрибуты) и может потенциально нуждаться (ассоциации), и как эта информация, вероятно, будет работать (методы), оттуда я определяю набор правил для управления согласованностью ресурсов (проверки).
Я обычно перебираю свой дизайн несколько раз, потому что действие определения других моделей обычно заставляет меня переосмыслить те, которые я уже сделал. Как только у меня появится модель, мне нравится, я начну рефакторинг или специализирующую (подклассифицирующую) модели, чтобы прояснить дизайн.
Я пишу миграцию и делаю скелеты для своих моделей. Обычно я не буду писать тесты, пока не будет представлен первый проект методов и проверок. Это не всегда очевидно, как реализовать вещи, пока они не проявят некоторую умеренную мысль.
Далее идет тестовый набор. Не имеет значения, что я использовал для написания тестов, пока я могу быть уверен, что бэкэнд является нормальным.
Это когда я собираю поток управления. Что происходит по успешному запросу? Неудачный запрос? Какие действия контроллера будут связаны с другими? Обычно есть сопоставление 1-1 между контроллерами и моделями (не считая подклассов моделей), каждый раз часто сталкиваюсь с ситуациями, когда мне нужно действовать по нескольким типам моделей, для чего я, вероятно, создаю новый контроллер. В зависимости от того, насколько сложно мое приложение, я могу моделировать поток как конечный автомат.
Наконец, я создаю представления. Я начинаю с создания пользовательского интерфейса, на который сильно влияют мои модельные отношения и атрибуты. Выделите общие части, затем напишите представления.
Польский интерфейс. Я создаю CSS и начинаю заменять ссылки с помощью удаленных вызовов или даже просто javascript, если это необходимо.
Я могу чередовать шаги 2 и 3. Мне очень легко написать тест сразу после того, как я напишу код для тестирования. Тем более, что я обычно тестирую вещи на консоли, когда пишу, а половина теста написана при вставке с консоли.
Я также могу разделять шаги 4 и 5 для каждой модели/контроллера. В любой момент я могу вернуться и пересмотреть предыдущее решение и распространить эти изменения с помощью своих шагов.
Я начинаю с эскизов пользовательского интерфейса, а затем перехожу к макетам HTML. По завершении разработки пользовательского интерфейса я могу определить ресурсы RESTful в приложении и их отношения.
Я не думаю, что писать только функции огурца, поскольку спецификации - хорошая идея. Написание тестового кода без возможности проверки его прохождения приводит к ошибкам в тестах и увеличивает время, необходимое для их исправления позже.
Итак, я бы сделал следующее:
Итак, вы напишете свои спецификации во время вождения своего приложения. Сохраняя его чистоту, а также сохраняя гибкость и возможность изменить некоторые идеи в середине проекта.