Day 26 什麽样的测试应该写,什麽样的不用?

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

决定要写什麽样的测试

工程师可能会写很多不同种类的测试。在 RSpec 里面,有 Model spec,Feature spec,Controller spec,Route spec 等等,你需要掌握所有不同类型的测试吗?当然不,那应该要跳过哪些测试呢?

你可能会想,测试不就是应该要覆盖率 100 % 吗?越多越好,但事实是这样吗?会不会其实不需要真的这麽做,只需要掌握几种重要的测试就好了!

我一定会写的两种测试

通常有两种测试是我一定会写的,就是 Model 以及 Feature 的测试,我会详细解释一下为什麽?

Model spec 是相对孤立的,一个 Model spec 将测试我的应用程序中特定的行为或是方法,例如有一个:Custom Model,Model spec 让我知道我的功能是可以被切成很细微的粒子,同时给予我信心,因为这些方法都会常常被的使用到,不论是在 Controller 或是 View。

例如,我有一个方法是回传客户的付款总额,那我就会替这个方法写一个测试。

确保应用程序的行为,在微观的情况下,每一个方法都能经得起测试,并且正确的执行!

而 Feature spec 呢?刚刚说过,Model spec 是很孤立的,但 Feature spec 则相反;他是一个集合体,验收整个应用程序的测试,Feature spec 让我相信所有的东西都能一起工作,例如:如果我的 Custom resource 有 CRUD 的功能,我就为了新增、修改、删除写 Feature spec!

测试术语

在测试的领域中,术语并没有达到共识,例如:有些人可能觉得 end-to-end 的测试、Feature spec 、验收测试是指同一件事,有些人可能觉得这三种是完全不同的测试类型。

这对於写测试意味着什麽?假设你看到 end-to-end 测试的引用和你对於 end-to-end 的理解不一致的话,这并不代表你的理解是错误的,因为并没有正确的答案,在测试的领域中很多东西都很模糊,并不是每个人都用相同且确切的术语在讨论相同的概念,但我认为这种沟通上的挑战是有帮助的,否则人们可能会因为明显的差异而受到干扰!

RSpec 对应的测试术语

Model spec 和所谓的验收测试是如何在 RSpec 中对应呢? Model spec 是活在 spec/models 目录中的测试。为了写 Model spec 除了原生的 RSpec 其他什麽都不需要。外界所提到的验收测试 ( 你可以说是 end-to-end 测试 ) 在 RSpec 中都被称为 Feature spec。由於 Feature spec 是通过浏览器来行使功能的,因此之前提过的 Capybara 就会是必要的!

顺便说一下,为什麽 RSpec 测试被称为 规格(spec) 而不是 测试 (test)?这个想法是,每个 RSpec 文件是一个 可执行的规范。在 RSpec 术语中,每个测试案例都被称作是一个 example 例子,一个关於该功能应该如何表现的例子。一堆的例子成就了一个规范。但其实这是在英文上的差别啦,在台湾大家都还是说测试测试,不太会有人硬要说这是一个规格,除非在写文章强调正确性才会,或是要写成英文的话,就会用 spec 而不是 test

我觉得意义不大的测试

我自己觉得 View spec、Route spec、Request spec、Controller spec 的意义就不太大,让我们分开来讨论一下。

Request spec、Controller spec

首先是术语:Request spec、Controller spec 是两件非常不同的事情,尽管为了我们的目的,我们可以把这两个看作是同一个事情,而且 RSpec 官方也在推广 Request spec 这件事,所以事实是, Request spec 是新的用法、也是一个新的术语。

不太写这个的原因是,我们都希望 Controller 可以越瘦越好,所以其实 Controller 本身并没有什麽商业逻辑,通常是都是调用 Model 的实体在做事情,所以不论是 Request spec 或是 Controller spec 都是可以被 Feature spec 给覆盖的,所以我更倾向让 Feature spec 去做这件事!

View spec、Route spec

说实在我不知道 View spec 的价值是什麽,我也没有看过哪些教学会真的希望你去写 View spec,原因是这些东西都会被 Feature spec 给覆盖,且它的功能 Feature spec 都有提供。

而 Route spec 也是一样的道理,也有许多的层面都是被 Feature spec 给覆盖。

小结

这次是把自己看了蛮多测试书後的感想写出来,因为真的有蛮多的东西在 Wiki 上的解释和 RSpec 里面是有灰色地带,真的会因为术语太多而搞不清楚情况。

而对於有些 RSpec 提供的测试,自己也没有很常使用,因为 Model spec 以及 Feature spec 就能有效的覆盖大部分的情形。

如果有什麽想法也可以留言告诉我喔!可以一起讨论~


<<:  Day25 NodeJS中的前端框架 I

>>:  【Day 24】Hook 06:useRef

CSS Position

前言 position 是用来设置元素定位的属性 Position分成了static 、fixed、...

Day 09 - Kbars 转换及储存至资料库

因前篇谈到透过api.kbars抓取1分K的资料内容,但我们在看盘或盘後分析时,可能会用到其它类型的...

DAY 2:Single Threaded Execution Pattern,门就只有一个大家好好排队啊~

什麽是 Single Threaded Execution Pattern? 透过 lock,只会有...

目录页 : 成为Canvas Ninja ~ 理解2D渲染的精髓

Day1 - 序言 - 成为Canvas Ninja ~ 理解2D渲染的精髓 基础篇 Day2 -...

[Day 17] 实作 Ktor OpenAPI Generator

先前有提到整个 OpenAPI 的运作流程是… 开发者为 route 撰写 OpenAPI defi...