Context Method

首先，想要測試 even? 這個方法，可以看到我們在 even? 前方加上了一個 # 的符號，這是為了要區別類別方法以及實體方法的小記號，若是測試類別方法則會使用 .some_method method 的寫法！

算是寫 RSpec 的一個小小的共識…嗎？

可以看到我們現在的測試項目非常的簡單好懂，就是期待奇偶數帶來不同的結果，這樣寫有什麼不對的地方嗎？

沒有，但可以更好！

RSpec.describe "#even? method" do
  it 'returns true if number is even' do
    expect(...)
  end
  it 'returns false if number is odd' do
    expect(...)
  end
end

為了讓語意更清晰，更容易閱讀，就有了箝套的概念，就像是你電腦的資料夾一樣，會整理相同邏輯的東西再一起，名字是圖片的資料夾裡面不會有 PPT 的報告，所以我們要來讓測試項目被分類，用具有脈絡的上下文來敘述！

RSpec.describe "#even? method" do

  context "when even number" do
    it "returns true" do
      expect(6.even?).to eq(true)
    end
  end

  context "when odd number" do
    it "returns false" do
      expect(9.even?).to eq(false)
    end
  end
end

完成！這樣就可以把剛剛很長又不容易讀的東西進行分類，也可以在某個 context 之下做延伸，例如當數字是奇數會發生…的測試。

就不會所有的測試都混成一團，看起來就沒什麼脈絡，還有另外一個好處，就是在終端機的 Output 會是一個箝套狀，看起超讚的！

而有些時候，你會看到有人用 describe 來替代 context，也沒有不行啦，兩者在實際做用上沒有什麼差別。

但大多數的人喜歡使用 context 在 describe 內，看起來才有區別的感覺，不然會滿滿整篇都是 describe

我們也可以看看 Better Specs 中有提到的：

整個 context 方法最重要的就是組織程式碼，使其易讀，且當你使用 context 時，請用 when with without 來做開頭！

解釋一個情境在測試的環境下也是很重要的，雖然對於非英語母語人士的我來說覺得好像沒什麼差別，但還是喜歡看到程式碼被組織起來的感覺。

結語

今天沒有提到太多的東西，但提供了一個我自己覺得很棒的網站，可以透過閱讀別人的 Coding Style 來提升自己寫 Code 的想法！

當今天學會了一種寫法，下次就會用那種思考方式來寫，一直不斷地提升自己，但如果一直只寫會動的程式碼，就會停滯不前

明天會先介紹 before & after 的差別，以及作用域的範圍，hooks 的先後順序等等。

其實開始學習程式後，理解程式碼的生命週期也是非常重要的一環！可以讓你理解整個流程的順序，這樣才知道是哪裡出錯、該從哪裡下手修改～

Robert Chang

技術部落格

RSpec - 用 Context 來組織程式碼區塊

Context Method

結語