Day 11 用 Context 来组织你的测试区块

该文章同步发布於：我的部落格

再开始介绍 Context 之前，想先推荐大家一个很棒的网站！

里面有介绍 RSpec 撰写的惯例，分别介绍了好的写法和坏的写法，当然这都是一个大多数人的共识，还是以自己工作的团队一致认同的 Coding Style 为准啊～

Better Specs，有空都可以看一下，通常会是 Good 的写法都有一些道理存在，容易阅读、语意清晰等等。

好啦～进入今天的正题：

Context Method

首先，我们想要测试 even? 这个方法，可以看到我们在 even? 前方加上了一个 # 的符号，这是为了要区别类别方法以及实体方法的小记号，若是测试实体方法会使用 .some_method method 的写法！

也是一个小小的共识！

可以看到我们测试的项目非常的简单好懂，就是期待奇偶数带来不同的结果，这样写有什麽不对的地方吗？

没有，但可以更好！

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

为了让语意更清晰，更容易阅读，就有了箝套的概念，就像是你电脑的资料夹一样，会整理相同逻辑的东西再一起，名字是图片的资料夹里面不会有 PPT 的报告，所以我们要来让测试项目被分类，用有意义的叙述！

RSpec.describe "#even? method" do

  context "with even number" do
    it "should return true" do
      expect(6.even?).to eq(true)
    end
  end
  
  context "with odd number" do
    it "should return 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 的先後顺序等等。

其实开始学习程序後，理解生命周期也是超重要的一环！可以让你理解整个流程的顺序，这样才知道是哪里出错、该从哪里修理～

明天见！