最近在学习Go
。然后不禁想感叹,为什么有些小伙伴的Go
测试可读性可以这么怪(cha)。说好的测试即文档呢?说好的测试边界呢?说好的Given When Then
呢?是我功力不行吗?
我一直相信,编程思想或说方法论都属于可迁移的知识,不管在哪种语言体内。可是看完一些 Go
的测试栗子,我开始慌了~
理想与现实
不信?看官请看:
由于测试用例太长,没法截全。没错,太长,一屏都装不下。好奇的你,请戳 ->>> 戳我
不知道你品起来如何,反正我品起来着实有点苦涩。
这样的栗子,在awesome-go
列表的开源库,还不少。不行,不行,不能被带歪了(PS: GitHub 的确是全球最大的基友社区啊,容易带歪人,hahaha)。
插播一条:多品整洁,简单的代码,有利于保护发际线。
当然不能“一棒子打死船人”,要有发现美的眼睛。看官请看:
这是大神TJ Holowaychuk
写的,果然不同凡响。好奇的你,请戳 ->>> 戳我
落地梦想
满足什么条件的测试,是值得品味的?我觉得,第一是可读性
,第二还是可读性
,第三还是可读性
。
常听说 测试即文档,那么问题来了,好读的文档,长啥样?读小学的时候,老师就有教导说,写作文要,结构清晰,中心思想突出!!!
写测试代码也是如此,要写出她(计算机)能理解的“文章”,也要写出我们能品的“文章”。那么,落地BDD
模式的测试,无疑是种好的选择。
看官请看:
中心思想突出,结构清晰。开头先描述主要功能,然后根据不同用例场景分别对待描述。
落地的栗子:
有木有看起来很舒服!!!你是不是在想,测试实现代码呢?看官您接着看:
完整栗子,好奇的你,请戳 ->>> 戳我
上面的栗子,落地就是测试三段式,GIVE-WHEN-THEN
:
- Given: set up context for a behaviour
- When: specify some action
- Then: specify some outcome
Action + Outcome = Behaviour
,行为是测试关注的核心。Given
,测试用例业务场景的准备,主要包含准备业务数据、Mock 外部依赖、准备用户信息。 随着业务的越复杂,测试上下文的准备也会越来与复杂,准备业务数据的过程也会越来越耗时间。举个栗子,对于API
测试来说,相对需要花时间写的就是Given
的过程。Then
,主要是写断言,Assert
一下API
的返回数据,When
,触发的动作,就是简单的发一下请求,调用一下API
。
在插播一条:如何解决 Given
编写耗时的问题,DSL Fixture
了解一下。
写在最后
咖啡喝完了,接下来我也不知道怎么写了,点到为止吧,因为后面的我也不会啊...
有疑问加站长微信联系(非本文作者)