Rails集成测试学习总结

最近开始接触rails集成测试（可见同事分享的《简介如何测试Rails应用
》），学习了些皮毛，来跟大家分享一下，写得不好或者不对的地方请大家多多指教。

环境搭建

鉴于本人是新手，测试环境是同事们帮忙搭建了，搭建环境对于我来说实在是太复杂啦ˊ_>ˋ。

测试环境：

• 安装rspec和rspec-rails
• 安装factory－girl
• 安装selenium-webdriver

rails中集成测试的步骤（feature -> background -> scenario）

# spec/features/vistors_spec.rb
require 'rails_helper'

feature "as a user, I should be able to visit all pages", type: :feature do
  background do
    @user = create(:internal_user, :active_role)
    login_as @user

    visit "/"
  end

  scenario "I should be able to visit sign up page" do
    visit "/users/sign_up"

    expect(page).to have_field "user[username]"
    expect(page).to have_field "user[email]"
    expect(page).to have_field "user[password]"
  end
end

使用user story作为测试内容

用户故事（User story）是指在软件开发和项目管理中用日常语言或商务用语写成的句子。这个句子反应终端用户或系统用户捕捉到的关于一个用户在其工作职责的范围内做的或需要做的事务。（维基百科）

用户故事的三大要素为：

• 角色：谁要使用这个功能。
• 活动：需要完成什么样的功能。
• 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

feature "as a user, I should be able to visit all pages", type: :feature do
  scenario "I should be able to visit sign up page" do
  end
end

这里选择用user story作为测试内容，一是可以模拟用户的真实操作，二是阅读上更方便测试以外的人理解。

集成测试的代码风格（dsl，封装Helper）

目前我还只会写一些简单的测试，那么当我遇到比较刁钻的问题时，要怎么办呢？这个时候就要去抱开发的大腿啦(=ﾟωﾟ)ﾉ，让他们帮忙写helper。

由于测试中很多功能都是有关联性的，这就难免会涉及到要重复写测试代码，所有就要把很多地方要用的功能封装成helper，就可以避免繁琐的工作量，代码也会更简洁，以及更好的维护。

scenario "create a new task", :js => true, type: :feature do   
  create_a_task_with title: "Client Meeting", text: "have meeting with the client at office"
end

# "创建任务task" 这个步骤在很多场景里是重复出现的，那么可以封装成一个helper，以后在需要用到场景里使用简单的、直白的Helper方法
def create_a_task_with(title:"" , text:"")
  find(".new-task-button").click
  find(".title-editable").set(title)
  find(".rich-editor").set(text)
  find(".save-recurrence").click
end

总结、感悟

总体来说，自动化测试减少了测试人员对功能重复测试的工作量，轻轻松松打一行代码，就能自动测试大部分的功能(☆_☆)，有时还会发现代码里面的bug，这是平时手工测试发现不了的问题。

写了一段时间的集成测试，现在只能写一些比较简单的测试，而且写的代码比较粗糙，用的是比较笨的方法，也明白了比较复杂的代码应该要封装起来，而不是直接写在测试代码里面，日后还要重构一下才行，要学的东西还很多呢(´･_･`)！