Rails 5 Test Prescriptions 第5章 Testing Models

Rails，model层包含业务逻辑和储存逻辑。其中储存逻辑被ActiveRecord处理。

在model中，不是每件事都必须是ActiveRecord对象。model layer可以包含各种服务，对象的值，或其他封装逻辑的类并使用ActiveRecord对象来储存。

 

• what can you do, 答案：type::model,没啥新东西,测试model✅
• what makes a good Set of Model Tests?✅
• Refactoring Models ✅
• a Note on Assertions per Test✅简单看了
• Testing what Rails Gives you ✅
• Testing ActiveRecord Finders⚠️没仔细看
• Testing Shared Modules and ActiveSupport Concerns ⚠️未看
• Writing Your own RSpec Matchers ✅

 

---

 

What Makes a Good Set of Model Tests? 

write a simple test, make it pass, then refactor ,这是经典回答。

但是，这没法给你很多有用的指导或为添加一个较大的功能提供方向。

 

A TDD Metaprocess

 

 

1. 测试初始状态
2. 简化成功的路径。
3. 替换alternate成功的路径，并反复做这个步骤
4. Error and Edge Cases that break code, 反复做这个步骤。

 

 1.初始状态。(此时不涉及逻辑，建立类和确定实例变量的初始状态)（如果已经现存一个类，则可以省略这部分）

 2 决定一个驱动这个新的逻辑的主要案例case。有时候会有多个。需要列出表单。

 3 在这些测试中，目标是让测试快速通过，然后重构。

 4当主要案例通过了，可以试着找打破现存代码的可能方法。（强壮你的代码，边缘测试）

 5之后移到下一步。 

---

Refactoring Models 

在TDD中，大量的设计发生在重构这步。因此重构很重要。重构让你思考你的代码如何更好。

忽略重构会让你处于危险中。

三件工作：

打破过于复杂的，整合重复的，abstractions waiting to be born. 分离那些等待出生的代码

 

Break up Complexity:

复杂的测试，表现在过长的方法和过长的代码。 一个好办法是提取部分代码成为自定义的方法。让方法名可读可理解。

 

• 把复合的多功能的boolean逻辑表达放入它自己的方法。 如valid_name?
• 本地变量，减少本地变量
• 在长方法中,看到inline comments,提取，(不理解，pass)

Combine Duplication 

如数字，第1章有案例。把数字提取出来变为方法，把以后会变动的数字以它的相关功能命名。

 

def max_point_count

  5
end

重复的逻辑也需要组合，如放入一个方法中，命名一个好理解的名字。

注意不同的逻辑，可能会有类似的名字。

 

Find Missing Abstractions 

重复的结构，意味着没有抽象。可以把一些代码放入一个新类中。

比如一堆实例属性如果总在一起使用 ，一组有相同前缀或后缀的方法。

可以写一些小类，用于储存方法。 

---

 

A Note on Assertions per Test 

每个测试都应该有注释说明。

aggregate_failure可以把类似的期望放在一起，一个有错误，不影响其他的测试。 

it "marks a task complete" , :aggregate_failures do  

...

end

也可以单独成块, aggregate_failurs do..end

 

Prescription 

Expectations that cover different branches of the application logic

should be handled in separate specs. 

 

---

 

Testing What Rails Gives You 

 Rails 提供了内置的关联和验证。 

 关联和validations功能是暗含在feature tests中的。我们在测试用户行为的过程中，就验证 了。

  

---

Testing ActiveRecord Finders 

测试数据查找方法。

Task.where(status: completed).order("completed_at DESC").where("size > 3").limit(5). 

可以把这些查找方法提取出来，以易懂的名字来做成方法。这样今后就比较好维护和反复使用。

 

(文章太长，看了一遍，不翻译了。因为好多知识点，不用是不能理解的。) 

 

 

---

Testing Shared Modules and ActiveSupport Concerns 

(文章太长 ,未看）
 

---

Writing Your Own RSpec Matchers 

https://relishapp.com/rspec/rspec-expectations/v/3-7/docs/custom-matchers/define-a-custom-matcher 

自定义匹配器放在spec/support中，在rails_helper中，去掉注释：

Dir[Rails.root.join('spec/support/**/*.rb')].each { |f| require f } 

例子：

在spec/support/size_matcher.rb中

RSpec::Matchers.define :be_of_size do |expected|

  match do |actual|

    actual.size == expected

  end

end 

RSpec::Matchers.define传递一个matcher的名字和一个block。

块带一个参数，是被期待的值。参数可以有多个。

在块内，match方法带一个块被调用，块带的参数是actual值。 

在match块内，自定义代码，==等式，实际值和被期待的值的互动。相等则返回true。

expect(actual_value).to be_of_size(expected_value) 

以上是基本用法。

自定义功能晚上，还有扩展的功能，?链接，如重写failure_message,  重写description,

重写failure_message_when_negated.等待10多个扩展功能

 

重要：chain方法，可以带参数和块，用于扩展自定义的方法。

chain :for_incomplete_tasks_only do

  @incomplete = true

end

 

这样在测试中就可以这么写了：

it "can calculate remaining size" do
  expect(project).to be_of_size(5).for_incomplete_tasks_only

end

 

---

What You’ve Done 

本章学习了model测试的策略技巧。了解了一下使用TDD测试来增加一个功能的过程。

下章讲关联测试数据。 

 

 

 

  

 

 

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