Rspec: everyday-rspec实操: 第10章测试其他功能，第11章TDD 第12章总结。

10.测试文件上传

作者推荐的Paperclip，官方维护组已经不推荐使用deprecated。

推荐使用rails自带的 ActiveStorage.

Active Storage:

推进文件上传到云存储，并附加这些文件到Active Record object。它 和本地驱动服务一起用于开发和测试。也支持反射文件到附属服务作为备份backups and migrations。

http://guides.rubyonrails.org/active_storage_overview.html

首先，编写针对文件上传功能的测试(用的是Capybara的方法)，并提供要使用的文件。attach_file "Attachment", "#{Rails.root}/spec/files/attachment.jpg"

接着，指定测试专用的上传路径。

最后，让 RSpec 在测试结束后清理文件。spec/rails_helper.rb

RSpec.configure do |config|
# 省略这个块里的其他内容 ...

# 测试组件运行完毕后清理上传的文件

config.after(:suite) do

FileUtils.rm_rf(Dir["#{Rails.root}/spec/test_uploads/"])

end

end

这是在功
能层测试文件上传的三个基本步骤。如果你用的不是 Paperclip，参阅上传库的文档，找出实现这三步的
方法。

---

10.3 测试电子邮件发送

大概浏览。会用到ActiveJob::TestHelper的方法

10.4  web 服务的测试，（⚠️没看）

---

---

---

第 11 章 迈向测试驱动开发

首先编写测试，然后编写能
让测试通过的代码，最后重构，从长远利益重新审视代码的实现方式。

在这个过程中，测试影响代码选择，力求写出没有缺陷的软件，而且新需求出现时，也不担心更新会破坏现有功能。

pending: (adj) waiting to be decided or settled.

11.1 feature test

• 添加一个按钮，用于把项目标记为已完成;

• 用户登录后控制台中不显示已完成的项目。

第一，在动手之前，先运行整个测试组件，确保添加功能之前所有测试都能通过

然后，新建feature test, 并列出要做的事情，用注释标记在scenario中。

之后，编写测试代码，把注释替换为真正的步骤。

11.2 from red to green

再次运行测试rspec spec/features/xxx_spec.rb --tag foucs

发现❌ 

Failure/Error: click_button "Complete"   

Capybara::ElementNotFound:

Unable to find visible button "Complete"

编写缺少的程序代码 视图中的按钮

然后在运行测试发现❌

Projects user completes a project  

Failure/Error: expect(project.reload.completed?).to be true

NoMethodError:

undefined method `completed?' for #<Project:0x00007f97b4392698>

根据RSpec的提示，根据业务逻辑编写代码，不同的业务逻辑意味不同的实现方法。

这里是通过用户的操作，点击按钮来判断project.completed?

因此需要定义completed?方法。这个方法根据项目中任务集合是否为空进行判断。

应该把是否完成设置为Project属性，用于储存是否完成的状态。

所以应该为Project添加属性completed: boolean。

$ bin/rails g migration add_completed_to_projects completed:boolean
$ bin/rails db:migrate

这里面临设计抉择？ 使用哪个路由处理点击按钮后更新database的操作。可以使用Project的

update动作。也可以添加一个新的动作。还是添加新动作吧。

需要更改view，controller, route。

view: 按钮添加路径complete_project_path(@project)

然后测试，看提示说没有路径，继续添加路径：

route: 在 resources :projects 块内增加patch "complete", on: :member

然后测试，看提示说没有action: complete，于是在控制器添加动作complete:

def complete..end

⚠️，测试驱动开发的原则之一是，为了让测试驱动推荐，每次尽量少添加新代码。

再测试，发现提示

Projects user completes a project

Failure/Error: unless @project.owner == current_user

NoMethodError:

undefined method `owner' for nil:NilClass

这是因为有钩子方法，回调。于是在before_action :set_project中增加 :complete

再测试，发现提示：

Failure/Error: expect(project.reload.completed?).to be true

expected true   got false

已经到了测试控制器动作了，但我们之前没写细节，所以❌。完善动作。

再测试，发现提示：

Failure/Error: expect(page).to have_content "Completed"

没有找到Completed字符串，这是因为我们没有在页面添加上

在视图山添加个标签<span>。

再测试，发现提示：
Failure/Error: expect(page).to_not have_button "Complete"

expected not to find button "Complete", found 1 match: "Complete"

项目完成，原来的Complete按钮应当改变.在view中改名其结构，增加if语句。

再测试，通过！Finished in 2.4 seconds
1 example, 0 failures

去掉:focus标签，运行整个测试bin/rails rspec看局部改动是否破坏整体功能。

11.3 from outside to inside 由外而内


大多数时候，RSpec提高的反馈是明确的，但有时候，需要深入研究才能找到线索。

这时可以使用gem 'launchy'调试，save_and_open_page.

但通常要编写更多的测试才能理解问题所在。

这些额外的测试在不同的层级监管代码，对初始的测试进行补充。

这就是由外而内的测试。

如果模拟浏览器测试显得大材小用，也可以使用低层级的测试。如控制器测试。

集成测试用的是模拟浏览器的功能测试，如果是测试API，使用request test。

然后通过低级 测试尽量直接测试细节，如模型层测试，或者用单独的Ruby代码测试。

11.4 red-green-refactor 循环





先练习编写简单的测试

多想，多做笔记

可以先写一些生产环境的代码，先试探一下。比如建立个git临时分支尝试。

尽量先编写集成测试TDD

合理规划测试时间，刚开始学习写测试肯定花费时间。

保持简单，基础扎实，再用更多的复杂概念 mock stub

遇到卡住失败测试，可以先标记一下，稍后再回来解决。

RSpec官方文档：



地址:

总文档连接：

RSpec.info/documentation/

https://relishapp.com/rspec/