自顶而下的TDD方法
通常，由于前面提到的两个原因（译者注：ActionRecord已经很好的被测试过，并且通过了功能测试），这类数据库测试是不需要的，但是我们还是做了这种测试，因为在一个针对n层应用的测试先行的垂直开发环境中，自顶而下的TDD流程才能被理解。
回到功能测试
既然User类存在并且数据库访问正常，是时候继续进行表示层的工作了。
实现list的行为和视图:
public void List()
{
PropertyBag["users"] = User.FindAll();
}
创建一个list.vm:
上面的视图中使用了GridComponent。现在运行测试，开发者应该会首次看到正常运行的UI测试。
编辑功能
下一步就需要给网站增加用户编辑的功能。 功能的流程是这样的：在用户列表页面，每一个用户都有一个编辑链接，一旦用户点击链接后会转到编辑页面，在那里可以修改用户的详细信息。当表单保存后，用户就返回到列表页面。现在编写测试:
一个用户被添加到了数据库，当列表网页被打开的时候，就有内容可以编辑了。但还有一个问题。如果测试运行两次，那么同一个用户将在数据库中被插入两次。为了避免这种潜在的错误，照下面这样做就可以了：
运行所有的测试，编辑的测试现在是失败的:
Selenium.SeleniumException: ERROR: Element link=Edit not found
at Selenium.HttpCommandProcessor.DoCommand(String command, String[] args)
at Selenium.DefaultSelenium.Click(String locator)
at MRProjectTest.Functionals.Selenium.ManageUsersTests.TestEditUser() in
ManageUsersTests.cs:line 28
为解决这个问题，在list.vm中添加编辑链接:
然后修改控制器中的行为:
public void Edit(long id)
{
PropertyBag["user"] = User.Find(id);
}
现在编辑这个行为的视图：edit.vm
因为值同样会被保存到update行为中，我们还会有下面的代码:
public void Update([DataBind("user")] User user)
{
user.Update();
RedirectToAction("list");
}
成功了!!
开始重构
还有机会在一些地方进行重构。首先，TestAddNew和TestEdit方法几乎相同：
同时:
运行测试，一切照样运行。现在进一步研究展示视图中的代码，它们有同样的问题：add.vm和edit.vm几乎如出一辙。 将公用部分单独放入_form.vm。运行测试依然可以确定该应用程序是正常工作的：
对于删除操作，同样可以利用“测试先行”的原理。对于数据验证或者用户可以使用的任何功能，添加新的测试，然后加入代码最终使其通过这些测试。
结论
这是一个使用增量体系结构的方法来利用TDD设计应用的例子。在实际的系统体系结构中，架构师与开发者不需要提前一个月进行设计。在代码被编写与测试时，架构和设计才被构建起来。在这种情况下，经常会有变化，因为持续重构代码可以使代码更加优化，这些都是TDD的原则与“测试先行”所支持的。
