Rails 5 Test Prescriptions(everday Rspectest作者推荐) 目录 1-3章

总文档连接： 

RSpec.info/documentation/ 

 

 

如何使用TDD 和 自动化测试来建立一个Rails app。

TDD让你用测试来探索代码的设计。你将学习可利用的工具，并学习用什么工具最好使。Tools comes and tools go, 工具是不断进化的，所以作者希望读者用最少的步骤写出更好的代码。

 

to help you write great app that do cool things and still catch the train home!

 

What's in this book?

开始介绍TDD,它为什么起作用，何时用TDD。

然后2章将使用RSpec来为新的Rails app 创建test.

之后几章节将单元测试基础，关于models, 多种方法生成测试数据，使用test doubles(替身) to simulate objects and specify hard-to-reach states.

然后end-to-end tests 集成测试和Capybara.

讨论JavaScript 先学习有JS 代码的end-to-end tests，然后学习JS单元测试。

然后,旅行到其他Rails部分，展示系统支持的工具。

12章还会了解使用Minitest来代替RSpec.

13-14章关于指定的场景测试，包括安全测试，测试第三方services.

15章 Debugging and Troubleshooting failing test.⚠️陌生

16章 关键写快速的代码和快速的写代码

17章 Legacy code 遗产代码，从他人那里继承的代码，等同于bad code. 

 

 What You'll Need

最新的Ruby2.5和Rails5.2,RSpec 3.7.1, Minitest 5.11.3

作者说RSpec学习曲线稍微陡峭，但这是业界使用最多的工具。Minitest 学习起来比较容易。

也就是经常说的： sometimes the best practice for learning isn't the best practice for experts. 

 

本书版本的更新：

 

• 控制器测试被抛弃，集成测试会被结合RSpe讲解
• JS内容是新增的，包括集成和单元测试。Rails Webpacker来开发JS代码
• Capybara 集成现在使用headless Chrome作为Javascript driver。
• 代码样本从写。 factory_bot作为数据创建方法使用在最新的测试中。 

 

下载代码案例 

 

---

第一章 一个预言故事

不写测试的问题是，重构的时候还要手动测试，而写自动化测试几行不花费额外的时间。 

写自动化测试可以防止你忘记测试的步骤。 

if you do testing well, your work will go faster。

TDD可以减少bug并且容易改正bug。 

TDD步骤：

 

1. 创建测试。每个测试都应当简单，做一件事情。
2. 确保测试失败。
3. 写最简单的代码来通过当前测试。不要担心完整的代码，不要过于向前，步子要小。 
4. 测试通过后，重构改进代码。 去除重复。然后再运行测试。
5. 重复以上步子

TDD的部分缺点：

当你不知道程序需要做什么的时候，TDD没有什么用。因为如果你不指定用什么断言／期望，就没法写测试。 比如view-testing：这时需要先写一部分代码然后马上测试，灵活一点，作者称为：test-next mode。

 

 

在写测试前，先列出一个测试清单，注明你要测试的内容，以防忘记。

在rails 社区，仍有讨论TDD 破坏代码的问题。 

作者认为TDD开发不能取代好的设计天赋，TDD仍可能创造bad code。 

 

---

第2章Test-driven development Basics

Prescription3:(药方->决策)

Initializing objects is a good starting place for a TDD process. Another good approach is to use the test to design what you want a successful interaction of the feature to look like. 

 

下面跟着案例章节走。只记录重点。 

Install RSpec

git init, #建立版本控制系统。

mkdir gatherer  -> cd gatherer

rails new .    -> bundle install

rake db:create:all   -> rake db:migrate

然后，安装gem 'rspec-rails'  ->再次bundle install

rails generate rspec:install #生成初始化文件

⚠️在.rspec, 加上--format documentation

rails spec  #测试是否安装成功。

 

Where to Start?

初始化对象是 TDD驱动测试开发的好的开始。另一个好方法是使用test来设计一个看起来成功的交互的功能。

建立spec/models/project_spec.rb，然后建立一个project的初始状态：

require 'rails_helper'

Rspec.describe Project do

  it "considers a project with no tasks to be done" do

    project = Project.new

    expect(project.done?).to be_truthy

  end

end

注解：

done?是自定义的方法， be_truthy是内建匹配器，判断actual_value是否是真，不是nil或false。

这是结构：expect(actual_value).to matcher

expect是RSpec定义的方法，接收任意object作为参数并return一个特殊的RSpec对象，这个对象被称为 ExpectationTarget. 

然后这ExpectationTarget将作为matcher方法的参数，最后返回结果。

  

Running the test

使用rspec, 所有目录的文件都会被加载。

每个RSpec文件需要rails_helper文件加载Rails环境，和spec_helper.rb,这里包含非Rails的步骤。

rails_helper.rb会建立固件或预置件。

每个顶级call to RSpec.describe创建一个内部RSpec对象叫做 example group.

example group使用块参数让describe方法被执行。describe方法里面也可以内嵌example groups。

每个descirbe方法内可能包含it方法，每个it方法创造一个独立测试，这个测试叫做example。

在每个example group中先运行before(:all) 在所有案例运行结束后，运行after(:all)

 

每个案例也有before(:example), after(:example) 钩子方法。

 

Making the Test Pass

 

运行rspec会报错， uninitialized constant Project，当然了我没建立这个类。

 

然后有3个不同的解决办法：

 

• 最purist way: 写最少的代码让当前错误通过，不考虑更大范围的事情。
• Practical way: 写你需要最终写的代码，忽略太小的没有价值的步骤（不用测试了）
• The teaching way: 介于前两者之间。让TDD既不要陷于细节之中，也不会忽略过多步骤。

 

作者的态度，偏重purer。作者的经历，有时候因为过于实际了，导致问题没有理解和忽略了本该测试的步骤。

 

app/models/project.rb

class Project

end 

然后再$rspec , ->undefined method `done?' for <Project:0x00007ff65db9b9b8> 

定义done?方法，再测试->expected: truthy value      got: nil

class Project

  def done?

    true

  end

end

测试通过！ 

 

---

The Second Test(只记录重点。)

建立了Task.Project and Task都没有继承ActiveRecord。作者的目的是一步步来。

---

 

let 

 

使用let重构。 let(:project) {Project.new}

let方法是一个语法糖。定义一个方法，调用这个方法会缓存这个结果。类似：

def me

  @me ||= User.new( name:   "Noel" )

end 

不调用就不存在。

let!  则是在定义let方法后，就始终存在:project变量 

 

---

 

be_comlete匹配器，是自定义的。

 

class Task

  def initialize

    @completed = false

  end

  def mark_completed

    @complete = true

  end

  def complete? #一定带 ？ 问号，才能成为匹配器be_complete

    @completed

  end

end

 

RSpec.describe Task, type: :model do

  let(:task) {Task.new}

  it "does not have a new task as complete" do

    expect(task).not_to be_complete

  end

 如果没有定义方法 complete?,测试会报错：

expected #<Task:0x00007fe3ac637da0 @completed=false> to respond to `complete?` 

 

---

 知识点： 

  def done?

    tasks.all? {|task| task.complete? }

    # task.all?(&:complete?)

    #这是单块方法，块参数的变形，具体需看<Ruby元编程>。 

  end

    # Enumerable#all?  传递每个元素到块如果每次块返回的是true，则all?方法返回true，否则返回false

 

 

---

 

Adding Some Math 

 作者在写测试前会想这个测试需要什么，典型的测试结构?️3部分：

 

1. Given： What data does the test need?
2. When:  What action is taking place?
3. Then :  what result(behavior) do I need to specify? 

 

Prescription:

选择你的测试数据，定义易于理解不重复的测试变量名字， 一旦发送错误，就容易诊断。

 

 

 

---

 

 知识点：

class Task

  attr_accessor :size, :completed

  def initialize( options = {})

    @completed = options[:completed]

    @size = options[:size]

  end

end

 

task1 = Task.new(size:1, completed: true) 

存储的 task1.@size 是1,

初始化参数是options= {size:1, completed: true}

所以@size = options[:size] = 1 

---

 

 The First Date

目的：把未完成的task和完成的task作个区分的同时，根据完成时间，体现出是近期完成(21天内)，还是非近期完成。 

根据测试数据的思考设计3步骤：

 

1. Given , 这个测试需要什么数据（测试的目的是什么）？完成的时间
2. When,  什么行为／方法正在发生？  task得到completed_at完成时间数据
3. then,   需要指定什么样子的结果behavior？  如果是近期的完成的工作，则返回ture。

 

 

增加2个案例： 

    it "doesn't count an incomplete task toward velocity" do

      expect(task).to_not be_a _part_of_velocity

    end

 

    it "counts a recently completed task toward velocity" do

      task .mark_completed(1.day.ago)

      expect(task).to be_part_of_velocity

    end 

修改代码：

⚠️a boundary-condition test :数据的设置体现在边界线及其两边。

 把Task表的completed属性类型从boolean改为date，名字改为completed_at

 

  def initialize(options = {})

    @size = options[:size]

    if options[:completed_at]

      mark_completed(options[:completed_at])

    end

  end

  def mark_completed( date= Time.current) #默认为当前时间

    @completed_at = date

  end

修改task.rb，增加1个方法。part_of_velocity

  def part_of_velocity?

    unless complete?

      return false

    end

    completed_at > 21.days.ago

  end

---

知识： Float#nan?

如果是一个不可验证的浮点数则返回NaN, 这个nan?方法是验证是否是nan 

a = 0.0/0.0   #=> NaN
a.nan?        #=> true

 

---

 

知识： 

对应可能会发生变动的数字，这个数字用到了多个不同类的实例方法中，可以使用类方法，而不是常量储存preserve这个数字。

  def self.velocity_length_in_days

    21

  end

以后改动就方便了。

 

---

 

What You've Done

Write a simple test, write simple code to make it pass, and refactor. 

TDD 的作用

当你开始做一个需求，而把这个需求转变为逻辑程序，你不能立即就弄清楚这个转变。

使用TDD你可以逐步的攻克这个问题。从小处，利于理解的角落开始，增加了对需求问题的理解后再开始较难的部分。 

 

转载于:https://www.cnblogs.com/chentianwei/p/9074630.html