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
- 测试初始状态
- 简化成功的路径。
- 替换alternate成功的路径，并反复做这个步骤
- 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测试来增加一个功能的过程。
下章讲关联测试数据。
