整个 Web （也不局限于 web）通常包括三个层面的代码 —— 单纯数据处理与运算、涉及到数据库、涉及到具体的网络协议。其中单纯的数据运算于处理主要为普通的运算的函数或者是其他代码，涉及到数据库就是传统意义上 MVC 里面的 M，涉及到具体的网络协议就是对应的 C。这三块的测试分别对应着第一节中常规的测试内容的前三条。
因为 C层面通常还可能涉及到页面的渲染以及相应协议的模拟，所以通常把测试的重心放在函数以及数据库相关的代码里面可以减少测试用例代码的复杂度，这个就要求 Controller 的代码要尽可能少。对于复杂度较高的应用的一些目前的一些建议：
将数据的基础校验都放在 M层，如果使用 Ruby 开发的话，ActiveRecord以及Mongoid都提供了很方便使用的 validation 功能。
尝试在代码中使用 Pub/Sub 模式配合一些 ORM中提供的钩子（hook） 来实现 Model 之间的通信。 例如在 A 创建的时候发布某个消息，B监听到消息之后修改他自己的某个属性值。
使用 Command 模式将一些业务无关的功能从系统中抽离出来，例如邮件发送。
以上建议参考：Laravel wisper resque
4. 构想
以上的内容都避开了前后端需要联调的测试用例，下面的内容主要是针对这块。Ruby 在这个方向已经有一些比较优雅的实现，感兴趣的可以直接先去欣赏一下 Capybara。
随着包括 Selenium Phantomjs 以及基于前者的 Watir 等一系列浏览器驱动的普及，使用代码控制浏览器已经不再是一件很复杂的事情。在这个能力的基础上，可以尝试把基于前端的测试分为四步：
等待某标志性元素出现（例如等待页面载入玩，或者某个内容异步加载出现）
模拟用户操作，这里的操作包括且不局限于用户点击、用户输入
等待反馈中标志性元素出现（例如某某输入框出现）
判断内容，是否符合预期
基于这个流程，可以解决绝大多数的前端测试。但是单纯依靠这个流程任然不够，因为页面中可能出现例如验证码这样的阻碍元素，在不修改代码的前提下，可以尝试通过数据库/缓存来取到这些内容。同样，和测试接口相同，这里也涉及到在测试前数据库中插入测试数据，测试用例执行后严重数据库里面数据变化，以及全部测试完毕后删除测试数据的内容。最终导致这块测试用例代码的实现需要同时对前端后端有一定的了解。目前还在考虑在借鉴 Capybara 的基础上，设计出更加通用的方案。
最后贴一段 Capybara 的代码结束这段内容：
feature "Signing in" do background do User.make(:email => 'user@example.com', :password => 'caplin') end scenario "Signing in with correct credentials" do visit '/sessions/new' within("#session") do fill_in 'Email', :with => 'user@example.com' fill_in 'Password', :with => 'caplin' end click_button 'Sign in' expect(page).to have_content 'Success' end given(:other_user) { User.make(:email => 'other@example.com', :password => 'rous') } scenario "Signing in as another user" do visit '/sessions/new' within("#session") do fill_in 'Email', :with => other_user.email fill_in 'Password', :with => other_user.password end click_button 'Sign in' expect(page).to have_content 'Invalid email or password' end end