Golang 的测试有点怪

最近在学习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 了解一下。

写在最后

咖啡喝完了，接下来我也不知道怎么写了，点到为止吧，由于后面的我也不会啊...

原文连接