Download as PDF, PPTX
![有三種路徑，你得執⾏行(⼿手動測 試)三次才能完整檢查 def correct_year_month(year, month) if month > 12 if month % 12 == 0 year += (month - 12) / 12 month = 12 else year += month / 12 month = month % 12 end end return [year, month] end](https://image.slidesharecdn.com/ihower-rspec-tdd-150604030608-lva1-app6892/75/RSpec-TDD-Tutorial-15-2048.jpg)
![1. Instant Feedback 寫好測試後，很快就可以知道程式有沒有寫對 it "should return correct year and month" do expect(correct_year_month(2011, 3)).to eq [2011, 3] expect(correct_year_month(2011, 14)).to eq [2012,2] expect(correct_year_month(2011, 24)).to eq [2012,12] end](https://image.slidesharecdn.com/ihower-rspec-tdd-150604030608-lva1-app6892/75/RSpec-TDD-Tutorial-19-2048.jpg)
![測試通過，即使還沒 實作 Item class Order attr_accessor :items def initialize self.items = [] end def <<(item_name) self.items << Item.new(item_name) end end](https://image.slidesharecdn.com/ihower-rspec-tdd-150604030608-lva1-app6892/75/RSpec-TDD-Tutorial-89-2048.jpg)
Uploaded byWen-Tien Chang
RSpec & TDD Tutorial
这是一个关于 RSpec 和 TDD 的教程，强调了自动化测试的重要性以及如何在 Ruby on Rails 项目中使用 RSpec。文档详细介绍了单元测试、集成测试、验收测试等基础概念，以及 TDD 的流程和最佳实践。重量级的知识点包括如何编写测试、使用 mocks 和 stubs，以及案例研究以提高代码质量和测试覆盖率。
RSpec & TDD Tutorial
- 1. RSpec & TDD Tutorial https://ihower.tw 2015/3 投影⽚片http://ihower.tw/presentation/ihower-rspec.pdf
- 2. About me • 張⽂文鈿a.k.a. ihower • http://ihower.tw • http://twitter.com/ihower • Instructor at ALPHA Camp • https://alphacamp.co • Rails Developer since 2006 • i.e. Rails 1.1.6 era
- 3. Agenda • Part1: RSpecand TDD • 什麼是⾃自動化測試和 RSpec • Continuous Testing and Guard • TDD and Code Kata • Mocks and Stubs • Part2: RSpec on Rails • model, controller, view, helper, routing, mailer, request spec • feature spec and capybara • Tools: spring, simplecov, cucumber • CI (Continuous Integration)
- 4.
- 6. Sorry, I’m notQA guy :/
- 7.
- 8. 單元測試 Unit Test 整合測試 Integration Test 驗收測試 AcceptanceTest Verification 確認程式的執⾏行結果有沒有對? Are we writing the code right? Validation 檢查這軟體有滿⾜足⽤用⼾戶需求嗎? Are we writing the right software?
- 9. 單元測試 Unit Test 整合測試 Integration Test 驗收測試 AcceptanceTest 測試個別的類別和函式結果正確 從⽤用⼾戶觀點測試整個軟體 測試多個類別之間的互動正確
- 10. 單元測試 Unit Test 整合測試 Integration Test 驗收測試 AcceptanceTest ⽩白箱測試 ⿊黑箱測試
- 11. 單元測試 Unit Test 整合測試 Integration Test 驗收測試 AcceptanceTest Developer 開發者 QA 測試⼈人員
- 12. Verification 確認程式的執⾏行結果有沒有對? Are we writingthe code right?
- 13. 我們天天都在檢查程 式的結果有沒有對 • 程式寫完後，⼿手動執⾏行看看結果對不對、 打開瀏覽器看看結果對不對? (如果你是web developer的話) • 聽說有⼈人只檢查 syntax 語法沒錯就 commit 程式的?
- 14.
- 15. 有三種路徑，你得執⾏行(⼿手動測 試)三次才能完整檢查 def correct_year_month(year, month) ifmonth > 12 if month % 12 == 0 year += (month - 12) / 12 month = 12 else year += month / 12 month = month % 12 end end return [year, month] end
- 16.
- 17.
- 18.
- 19. 1. Instant Feedback 寫好測試後，很快就可以知道程式有沒有寫對 it"should return correct year and month" do expect(correct_year_month(2011, 3)).to eq [2011, 3] expect(correct_year_month(2011, 14)).to eq [2012,2] expect(correct_year_month(2011, 24)).to eq [2012,12] end
- 20.
- 21. 2. 回歸測試及重構 • 隨著程式越寫越多，新加的程式或修改， 會不會搞爛現有的功能? •重構的時候，會不會造成破壞? • 如果有之前寫好的測試程式，那們就可 以幫助我們檢查。
- 22. 3. 幫助你設計 API •寫測試的最佳時機點：先寫測試再實作 • TDD (Test-driven development) • Red-Green-Refactor 流程 • 從呼叫者的⾓角度去看待程式，關注介⾯面， 協助設計出好⽤用的 API。
- 23. 4. ⼀一種程式⽂文件 • 不知道程式的API 怎麼呼叫使⽤用? • 查測試程式怎麼寫的，就知道了。
- 24. ⼩小結 • 你的程式不 Trivial-> 寫測試節省開發時間 • 你的程式不是⽤用過即丟 -> 回歸測試和重構 • TDD -> 設計出可測試，更好的 API 介⾯面 • API 怎麼⽤用 -> 測試也是⼀一種⽂文件
- 25.
- 26. xUnit Framework 每個程式語⾔言都有這樣的框架 • testcase 依序執⾏行各個 test : • Setup 建⽴立初始狀態 • Exercise 執⾏行要測的程式 • Verify (assertion)驗證狀態如預期 • Teardown 結束清理資料
- 27. Ruby 的 Test::Unit classOrderTest < Test::Unit::TestCase def setup @order = Order.new end def test_order_status_when_initialized assert_equal @order.status, "New" end def test_order_amount_when_initialized assert_equal @order.amount, 0 end end Method 的命名是 個⿇麻煩
- 28. describe Order do beforedo @order = Order.new end context "when initialized" do it "should have default status is New" do expect(@order.status).to eq(“New”) end it "should have default amount is 0" do expect(@order.amount).to eq(0) end end end RSpec 寫法
- 29. RSpec 第⼀一印象 • 語法Syntax 不同 • 程式更好讀 • 更像⼀一種 spec ⽂文件
- 30. RSpec • RSpec 是⼀一種Ruby 的測試 DSL (Domain-specific language) • Semantic Code：⽐比 Test::Unit 更好讀，寫的⼈人 更容易描述測試⺫⽬目的 • Self-documenting：可執⾏行的規格⽂文件 • ⾮非常多的 Ruby on Rails 專案採⽤用 RSpec 作為測試框架
- 31. RSpec (cont.) • 不是全新的測試⽅方法論 •是⼀一種改良版的 xUnit Framework • 演進⾃自 TDD，改稱 BDD (Behavior-driven development) • 先寫測試，後寫實作
- 32. Learn RSpec • syntax •syntax • syntax • more syntax
- 33.
- 34. describe Order do #... end # 或是 describe "A Order" do # ... end 要測的東⻄西是什麼? 通常是⼀一個 類別
- 35. 可以 Nested 加⼊入想要測試的 ⽅方法是哪個 describeOrder do describe "#amount" do # ... end end 通常開頭⽤用 # 表⽰示 instance method dot 開頭表⽰示 class method
- 36. 可以再 nested 加⼊入不同情境 describeOrder do describe "#amount" do context "when user is vip" do # ... end context "when user is not vip" do # ... end end end
- 37. 每個 it 就是⼀一⼩小段測試 Assertions⼜又叫作 Expectations
- 38. 加⼊入 it describe Orderdo describe "#amount" do context "when user is vip" do it "should discount five percent if total > 1000" do # ... end it "should discount ten percent if total > 10000" do # ... end end context "when user is not vip" do it "should discount three percent if total > 10000" do # ... end end end end
- 39.
- 40. describe Order do describe"#amount" do context "when user is vip" do it "should discount five percent if total >= 1000" do user = User.new( :is_vip => true ) order = Order.new( :user => user, :total => 2000 ) expect(order.amount).to eq(1900) end it "should discount ten percent if total >= 10000" { ... } end context "when user is vip" { ... } end end
- 41.
- 42.
- 43.
- 44. before 和 after •如同 xUnit 框架的 setup 和 teardown • before(:each) 每段 it 之前執⾏行 • before(:all) 整段 describe 執⾏行⼀一次 • after(:each) • afte(:all)
- 45. describe Order do describe"#amount" do context "when user is vip" do before(:each) do @user = User.new( :is_vip => true ) @order = Order.new( :user => @user ) end it "should discount five percent if total >= 1000" do @order.total = 2000 @order.amount.should == 1900 end it "should discount ten percent if total >= 10000" do @order.total = 10000 @order.amount.should == 9000 end end context "when user is vip" { ... } end end
- 46. pending 可以先列出來打算要寫的測試 describe Order do describe"#paid?" do it "should be false if status is new" xit "should be true if status is paid or shipping" do end end end
- 48. let(:name) { exp} • 有使⽤用到才會運算(lazy)，並且在同⼀一個 example 測試中多次呼叫會 Memoized 快取起 來。 • 相較於 before(:each) 可增加執⾏行速度 • 因此就不⽤用 instance variable 放 before 裡了， 增加程式可讀性 • let! 則是⾮非 lazy 版本
- 49. describe Order do describe"#amount" do context "when user is vip" do let(:user) { User.new( :is_vip => true ) } let(:order) { Order.new( :user => user ) } it "should discount five percent if total >= 1000" do order.total = 2000 order.amount.should == 1900 end it "should discount ten percent if total >= 10000" do order.total = 10000 order.amount.should == 9000 end end context "when user is vip" { ... } end end
- 50. ⼀一些別名⽅方法 哪個念起來順就⽤用哪個 describe Order do# describe 和 context 其實是 alias # it, specify, example 其實都⼀一樣 it { … } specify { … } example { … } end
- 51. ⼀一些慣例 • ⼀一個 rb檔案配⼀一個同名的 _spec.rb 檔案 • 容易找 • guard 等⼯工具容易設定 • editor 有⽀支援快速鍵 • describe “#title” 是 instance method • describe “.title” 是 class method
- 52. 輸出格式 • rspec filename.rb預設不產⽣生⽂文件 • rspec filename.rb -fd 輸出 specdoc ⽂文件 • rspec filename.rb -fh 輸出 html ⽂文件
- 53. HTML format⿎鼓勵寫出⾼高 speccoverage 程式，因為可以當做⼀一種⽂文件
- 54. Continuous Testing • 使⽤用guard-rspec • 程式⼀一修改完存檔，⾃自動跑對應的測試 • 節省時間，⽴立即回饋
- 55. Code Kata • ⼀一種練習⽅方法，透過⼩小型程式題⺫⽬目進⾏行 鍛鍊，就像學功夫套拳，重複練功⼀一樣 •除了⾃自⼰己練，也可以 pair-programming • TDD 需要練習才能抓到訣竅，與其說它 是⼀一種測試⽅方式，不如說它更像⼀一種設 計⼿手法 • 抓到 TDD 測試精神和訣竅，⽐比學再多漂 亮的語法糖更重要
- 56. 準備 Kata 環境 https://github.com/ihower/ruby-kata •Gemfile 設定 rspec, guard • 安裝 growl notification (optional) • bundle
- 57.
- 58. FizzBuzz • 逢三整除，輸出 Fizz •逢五整除，輸出 Buzz • 逢三五整除，輸出 FizzBuzz
- 59. LeapYears • 判斷閏年 • ⻄西元年份除以400可整除，為閏年。 •⻄西元年份除以4可整除但除以100不可整 除，為閏年。 • 其他則是平年
- 61. Roman Numerals • 轉換羅⾺馬數字 •1 -> I • 4 -> IV • 5 ->V • 9 -> IX • 10 -> X • 20 -> XX
- 62. What have welearned? • ⼀一個 it 裡⾯面只有⼀一種測試⺫⽬目的，最好就 只有⼀一個 expectation • 要先從測試 failed 失敗案例開始 • 確保每個測試都有效益，不會發⽣生砍 掉實作卻沒有造成任何測試失敗 • ⼀一開始的實作不⼀一定要先直攻⼀一般解， 可以⼀一步⼀一步在 cycle 中進⾏行思考和重構 • 測試程式碼的可讀性⽐比 DRY 更重要 • 安全重構：無論是改實作或是改測試碼， 當時的狀態應該要維持 Green As the tests get more specific, the code gets more generic. Programmers make specific cases work by writing code that makes the general case work.
- 63. Three Laws ofTDD • ⼀一定是先寫⼀一個不通過的單元測試，才 開始實作功能 • 每次只新加⼀一個單元測試，只需要剛剛 好不通過即可，不要⼀一次加多個測試情 境 • 每次實作功能時，只需要剛剛好通過測 試即可，不多也不少 http://programmer.97things.oreilly.com/wiki/index.php/The_Three_Laws_of_Test-Driven_Development
- 64.
- 65. Bowling Game • 計算保齡球分數 •X (strike) 累加後兩球分數 • / (spare) 累加後⼀一球分數 BowlingGame # roll # roll_many(1,2,3,4) # or roll_many(“1234512345”) # finished? # score http://www.sportcalculators.com/bowling-score-calculator
- 66. What have welearned? • 透過寫測試，定義出哪些是類別公開的 介⾯面(API) • 測試碼⽅方便呼叫的API，就是好API • 不需要公開的，定義成 private ⽅方法， 讓實作有更好的物件導向封裝。 • 不需要針對 private ⽅方法直接寫單元測 試，⽽而是透過 public ⽅方法間接測試
- 67.
- 68.
- 69. 當你在寫⺫⽬目標類別的測試和實作 時，這些 Collaborator... • 無法控制回傳值的外部系統(例如第三⽅方 web service) • 建構正確的回傳值很⿇麻煩 (例如得準備很多假資料) • 可能很慢，拖慢測試速度 (例如耗時的運算) • 有難以預測的回傳值 (例如亂數⽅方法) • 還沒開始實作 (特別是採⽤用 TDD 流程)
- 70. 使⽤用假物件 • 可以隔離 Collaborator的 Dependencies • 讓你專⼼心在⺫⽬目標類別上 • 只要 Collaborator 提供的介⾯面不變，修 改實作不會影響這邊的測試。
- 71. ⽤用 double 產⽣生假物件 @user= double("user", :name => "ihower") @user.name # "ihower" @customer = double("customer").as_null_object @customer.foobar # nil
- 72. 測試狀態 describe "#receiver_name" do it"should be user name" do user = double(:user, :name => "ihower") order = Order.new(:user => user) expect(order.receiver_name).to eq("ihower") end end
- 73. 測試⾏行為 Mock 如果沒被呼叫到，就算測試失敗 @gateway =double("ezcat") # 預期等會 @gateway 必須被呼叫到 deliver ⽅方法 expect(@gateway).to receive(:deliver).with(@user).and_return(true) # 發⽣生⾏行為，如果沒有就測試失敗
- 74. ⽤用來測試⾏行為的發⽣生 describe "#ship!" do beforedo @user = double("user").as_null_object @gateway = double("ezcat") @order = Order.new( :user => @user, :gateway => @gateway ) end context "with paid" do it "should call ezship API" do expect(@gateway).to receive(:deliver).with(@user).and_return(true) @order.ship! end end
- 75.
- 76. Partial mocking and stubbing •如果 Collaborator 類別已經有了，我們可 以 reuse 它 • 只在有需要的時候 stub 或 mock 特定⽅方法
- 77. Partial Stub 可以⽤用在任意物件及類別上，假造他的⽅方法和回傳值 user =User.new allow(user).to receive(:find).and_return("ihower")
- 78. Partial Mock 可以⽤用在任意物件及類別上，假造他的⽅方法和回傳值， 並且測試他必須被呼叫到 gateway =Gateway.new expect(gateway).to receive(:deliver).with(user).and_return(true)
- 79. ⼀一般測試流程 vs. Mock 測試流程 Given給定條件 When 當事情發⽣生 Then 則結果要是如何 Given 給定條件 Expect 預期會發⽣生什麼 When 當事情發⽣生
- 80.
- 81.
- 82. Classical Testing v.s. MockistTesting • Classical: 先決定你要完成的範圍，然後 實作這個範圍的所有物件。 • Mockist: 只針對⺫⽬目標類別做測試及實作， 不相干的⽤用假物件。
- 83. Mockist 缺點 • 你可能需要stub 很多東⻄西，nested stub ⾮非 常不好 • stub 的回傳值可能難以建構 • 與 Collaborator 的⾏行為太耦合，改介⾯面就要 跟著改⼀一堆測試。 • 承上，即使忘了跟著改實作，單元測試還是 會過... 例如在動態語⾔言中，可能 Collaborator 後來改了⽅方法名稱，但是 這邊的測試仍然會過...
- 84. 如何趨吉避凶? • 必須擁有更⾼高層級的整合測試，使⽤用真的物 件來做測試。 • 採⽤用TDD 思維讓 API 設計可以趨向: • 不需要 stub 太多層 • 回傳值簡單 • 類別之間的耦合降低 • 遵守 Law of Demeter
- 85. 採⽤用 TDD 並搭配 IntegrationTest 雖然有些 stub 和 mock 但是會設計出⽐比較好 的 API 讓副作⽤用較少 我的推論
- 86. 濫⽤用 stub 和mock 沒有⽤用 TDD，也沒有 Integration Test API 設計的不好，stub 的缺點就顯現出來的 我的推論
- 87. 不然，請⼩小⼼心： • ⽤用 Mocks來完全隔離內部 Internal dependencies • ⽤用 Mocks 來取代還沒實作的物件
- 88. 版本⼀一： 這個 Order 完全隔離Item describe Order do before do @order = Order.new end describe "#<<" do it "should push item into order.items" do Item = double("Item") item = double("item", :name => "foobar") allow(Item).to receive(:new).and_return(item) @order << "foobar" expect(@order.items.last.name).to eq(“foobar”) end end end
- 89. 測試通過，即使還沒 實作 Item class Order attr_accessor:items def initialize self.items = [] end def <<(item_name) self.items << Item.new(item_name) end end
- 90. 版本⼆二： 實作真的 Item 物件 (拿掉剛才的所有stub code 即可) describe Order do before do @order = Order.new end describe "#<<" do it "should push item into order.items" do @order << "foobar" expect(@order.items.last.name).to eq "foobar" end end end
- 91. 需要寫真的 Item 讓測試通過 class Item attr_accessor:name def initialize(name) self.name = name end end describe Item do it "should be created by name" do item = Item.new("bar") expect(item.name).to eq "bar" end end
- 92. 差在哪? 假設我們後來 修改了 Item的實作 class Item attr_accessor :name def initialize(name) self.name = name.upcase end end
- 93. 真的版本會有多個 Failure :/ Mocks版本則不受影響 :)
- 94. 但是如果 Item 改介⾯面呢? class Item attr_accessor:title def initialize(name) self.title = name.upcase end end
- 95.
- 96. 兩害相權取其輕 • 寧願看到重複原因的 Failure? •還是連 Failure 都捕捉不到，失去測試的意義?
- 97. So, 有限度使⽤用 • 造真物件不難的時候，造假的時間拿去造真的。 有需要再⽤用Partial Stubbing/Mocking。 (相較於 Java，在 Ruby 裡造物件很快) • 只在 Collaborator 不好控制的時候，Stub 它 • 只在 Collaborator 還沒實作的時候，Mock 它 • Collaborator 的狀態不好檢查或它的實作可能會 改變，這時候才改成測試⾏行為。
- 98. 造假舉例：Logger 已知有⼀一個 Logger 其log ⽅方法運作正常 # 測狀態 logger.log("Report generated") expect(File.read("log.log")).to eq "Report generated" # 如果 Logger 換別種實作就死了 # 測⾏行為 expect(logger).to receive(:log).with(/Report generated/) logger.log("Report generated")
- 99. 造假舉例： MVC 中的Controller 測試 #測狀態 it "should be created successful" do post :create, :name => "ihower" expect(response).to be_success expect(User.last.name).to eq("ihower") # 會真的存進資料庫 end # 測⾏行為 it "should be created successful" do expect(Order).to receive(:create).with(:name => "ihower").and_return(true) post :create, :name => "ihower" expect(response).to be_success end
- 100. Mocks ⼩小結 • 多⼀一種測試的⽅方法：除了已經會的測試 狀態，多了可以測試⾏行為的⽅方法 •有需要⽤用到來讓測試更好寫，就⽤用。不 必要⽤用，就不要⽤用。
- 101. Code Kata • TrainReservation HTTP Client library • GET /train/{:id} 拿列⾞車座位資料 • POST /train/{:id}/reservation 定位 • Ticket Office Web Service (Part 2)
- 102. What have welearned? • 利⽤用 Mocks 處理測試邊界(第三⽅方服務) • 設計 Web Service API (Part 2 會繼續沿⽤用)
- 103. 補充: HTTP Client測試 • 更⼀一般性的 Mock Library https:// github.com/bblimke/webmock • ⽤用錄的 https://github.com/vcr/vcr (for Facebook,Twitter, Google 已經存在的服 務) http://robots.thoughtbot.com/how-to-stub-external-services-in-tests
- 104. Reference: • The RSpecBook • The Rails 3 Way • Foundation Rails 2 • xUnit Test Patterns • everyday Rails Testing with RSpec • http://pure-rspec-rubynation.heroku.com/ • http://jamesmead.org/talks/2007-07-09-introduction-to-mock-objects-in-ruby-at-lrug/ • http://martinfowler.com/articles/mocksArentStubs.html • http://blog.rubybestpractices.com/posts/gregory/034-issue-5-testing-antipatterns.html • http://blog.carbonfive.com/2011/02/11/better-mocking-in-ruby/
- 105.