Behaviour Driven Rails（瞎翻译。附原文。）

晚上看到这个链接：http://ywencn.iteye.com/blog/605750
想起来之前自己草稿箱里还有下面这篇东东，也扔出来吧。刚好蜗牛翻译了后面部分。

传统的Rails开发(Traditional Rails Development)

Rails开发者通常使用由内而外的方式来开发应用程序。首先设计schema，并实现models。然后是controllers，最后是views和helpers。

Rails developers typically use an inside-out approach to developing
applications. You design the schema and implement models first, then
the controllers, and lastly the views and helpers.

这样的过程会使你在系统的其它部分存在之前创建一些你相像中的将会被用到的东西。这种开发过程一开始进展得很快，但是经常会导致你创建一些不能以你相像中的方式使用的东西，或者根本就用不到。当你意识到model并没有按照你设想的方式工作的时候，你要么回想一下你已经创建了些什么，要么就凑合着继续干。在这个关键时刻，你的良心可能会告诉你“做最简单的事”。

This progression has you build things you think other parts of the system
are going to need before those other parts exist. This approach
moves quickly at first, but often leads to building things that won’t be
used in the way you imagined, or perhaps won’t get used at all. When
you realize that the models don’t really do what you need, you’ll need
to either revisit what you’ve already built or make do. At this juncture,
you might hear your conscience telling you to “do the simplest thing.”

由内而外的开发方式中，“简单”的假象(The Illusion of "simple" with Inside-Out)
by Zach Dennis
我曾经做过一个显示用户事件(events)的应用程序。采用由内而外的方式开发，我们创建了一些我们认为足够描述应用程序的models，包括一些按照一系列用户的条件查找events的自定义搜索功能。当我们到了实现views的时候，我们认识到我们需要根据一些额外的条件来过滤events的列表：event是属于user还是属于user所在的group？user的身份是admin吗？

I once worked on an application that had to display events to a user.
Working inside-out, we had built several of the models that we felt
adequately represented the application, including some custom search
functionality that would find events based on a set of criteria from the
user. When we got to implementing the views we realized that we needed
to filter the list of events based on some additional criteria. Did the event
belong to the user or to a group the user belonged to? Was the user an
admin?

我们已经建立起了events和users、groups的关联，与其回头修改自定义搜索功能，看起来不如利用我们已经建立的东西来得简单。于是，我们把那些检查条件的代码添加到了views上，而不是重构model(refactoring the model)来提供额外的过滤规则。然后我们重构了页面，把这些检查代码提取到了helper module中，错误的减轻了我们把逻辑放入views的罪恶感。对于这个决定我们当时觉得还不错，我们认为自己是实用主义的(pragmatic)，做的是最简单的事(the "simplest thing")。

We had already set up the associations for events belonging to users and
groups. Rather than go back and change the custom search functionality,
it seemed simpler to take advantage of what we had already built. So
instead of refactoring the model to support the additional filtering, we
added those checks in the views. Afterwards we refactored the view,
extracting the checks to a method in a helper module, erroneously easing
our guilt over putting logic in a view. We felt good at the time about the
decision. We were being pragmatic and doing the “simplest thing.”

随着时间的推移，我们遇到许多类似的情况，并且做出了同样的决定。不久，这个程序在难以重用和使用的地方到处隐藏着这种“简单”。最后我们确实需要在程序的其它地方重用一部分逻辑，但是这（重用）已经再也不简单了。现在我们似乎不得不权衡这3种罪行并从中做出选择：为了重用强制使用一些不优雅的方法访问逻辑、复制逻辑或者回头在程序上做一个费时的外科手术，使它更容易使用。

Over time, we were presented with similar situations and made similar
decisions. Before long the application had all of this “simple-ness” tucked
away in places where it was very difficult to re-use and work with. We did
end up needing to re-use some of this logic in other parts of the
application, but it wasn’t simple any longer. Now it felt like we had to
choose between the lesser of three evils: force some awkward way of
accessing the logic for re-use, duplicate the logic, or go back and perform
time-consuming surgery on the application to make it easier to work with.

从models到views的构建顺序意味着你将基于你认为你需要的东西写代码。讽刺的是，当你专注于UI的时候，你才会发现你在modles上真正需要的是什么，但到那个时候，已经有了一群开发好了、重构过的并且被很好的测试过的的支持代码(supporting code)等着你使用（我的理解是，这些已经写好的“支持代码”当中，往往有些你最后用不到，或者不能按照实际的需求来工作。也就是说，自底向上——文中的说法是由内而外——的开发比较脱离需求，是基于假设的开发过程。这里边如此的强调自顶向下，我就不明白为啥论坛上老有人说TDD必须是自底向上的。比如这个：http://www.iteye.com/topic/480096，再比如：http://www.iteye.com/topic/583164#1369471，那真的是TDD吗？）。

Building from the models out to the views means writing code based
on what you think you’re going to need. Ironically, it’s when you focus
on the UI that you discover what is really needed from the models,
and at that point there’s already a bunch of supporting code developed,
refactored, and well tested—ready to be used.

实事证明，你可以通过由外到内的开发方式来减缓这些问题，并且建立起你真正需要的而不是你假设你需要的……的……的东西。

It turns out that you can alleviate these issues and build what you need
rather than building what you think you need by working Outside-In.

由外到内的Rails开发(Outside-In Rails Development)

由外到内的Rails开发则是把由内而外的开发过程倒过来。按从views到models的顺序开发，而不是从models到views。

Outside-in Rails development is like standing the traditional inside-out
approach on its head. Instead of working from the models out to views,
you work from the views in toward the models.

这种方式由客户认可的标准来驱动开发，是更直接的方式。这种方式会使你在项目的早期处于一个更好的位置来更好的发现程序中的对象和接口，同时基于真正的需求做出设计决策。

This approach lets customer-defined acceptance criteria drive development
in a much more direct way. It puts you in a better position to
discover the objects and interfaces earlier on in the process and make
design decisions based on real need.

#

The BDD cycle with Rails is the same Outside-In process you’d use with
any other framework (or no framework), web, desktop, command line,
or even an API. The cycle depicted in Figure 17.1, on the following page
is the same cycle depicted in Figure 1.1, on page 19, but we’ve added
some detail to help you map it to Rails.

以一个场景开始。确保你能够清晰的理解这个场景以及它该如何工作，包括……接：http://ywencn.iteye.com/blog/605750

Start with a scenario. Make sure you have a clear understanding
of the scenario and how it is expected to work, including how the
UI should support a user interacting with the app (see the sidebar
on page 201)..........