我正在为客户启动Rails应用程序，并且正在考虑创建思维导图或直接跳到Cucumber规范。
您如何规划您的Rails应用程序？
作为一个额外的问题，假设你也从Cucumber开始，那么你会在哪一点上编写单元测试？在满足规范之前？
答案 0 :(得分：38)
我有一个6步骤的过程。
我更喜欢在做任何事情之前弄清楚模型关系并使用它。通常，我尝试将模型定义为包含连贯信息块的单元。通常，这首先要确定我的应用程序需要的正交资源（用户，帖子等）。然后我找出每个资源绝对需要的信息（属性），可能需要（关联），以及如何在（方法）上操作该信息，从那里我定义了一组规则来管理资源的一致性（验证） ）。
我经常迭代我的设计几次，因为定义其他模型的行为通常会让我重新思考我已经做过的事情。一旦我有一个我喜欢的模型设计，我将开始重构或专门化（子类化）模型以阐明设计。
我编写了迁移并为我的模型制作了骷髅。在我实施方法和验证的初稿之前，我通常不会编写测试。在给予一些温和的思考之前，如何实施它并不总是显而易见的。
接下来是测试套件。无论我以前写过什么测试，只要我能确定后端是否合理。
这是我将控制流拼凑在一起的时候。成功请求会发生什么？不成功的请求？哪些控制器操作将链接到其他人？通常控制器和模型之间存在1-1映射（不计算模型的子类），每次我都会遇到需要对多种模型类型进行操作的情况，因为我可能会创建一个新的控制器。根据我的应用程序的复杂程度，我可以将流程建模为状态机。
最后我创建了视图。我首先勾勒出基于UI的模型，该模式受到模型的关系和属性的影响很大。摘要出公共部分，然后写出意见。
修改用户界面。我创建了一个CSS，并开始用远程调用替换链接，甚至在适当的时候只使用javascript。
我可能会交错步骤2和3.我发现在编写要测试的代码之后编写测试非常容易。特别是因为我在编写时经常在控制台中测试一些东西，而一半的测试是通过从控制台粘贴来编写的。
我还可以为每个型号/控制器划分步骤4和5。我可以回过头来修改一个先前的决定，并通过我的步骤传播这些变化。
答案 1 :(得分：5)
我从用户界面的草图开始，然后进入HTML模型。完成UI设计后，我可以识别应用程序中的RESTful资源及其关系。
答案 2 :(得分：4)
我不认为只编写黄瓜功能作为规格是一个好主意。编写测试代码而不能测试它会导致测试中的错误，并增加您以后需要更正它们的时间。
所以我会做以下事情：
因此，您可以在驾驶应用程序时编写规范。保持清洁，同时保持敏捷，并能够在项目中间改变一些想法。