28 | test::nginx 还可以这样用？

Jul 29, 2019

28 | test::nginx 还可以这样用？-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

28 | test::nginx 还可以这样用？

2019-07-29 温铭来自北京

《OpenResty从入门到实战》

课程介绍



讲述：温铭

时长08:24大小7.70M



你好，我是温铭。
在前面两个章节中，你已经掌握了 test::nginx 的大部分使用方法，我相信你已经能够看明白 OpenResty 项目中大部分的测试案例集了。这对于学习 OpenResty 和它的周边库而言，已经足够了。
但如果你有志于成为 OpenResty 的代码贡献者，或者你正在自己的项目中使用 test::nginx 来编写测试案例，那么你还需要来学习一些更高级、更复杂的用法。
今天的内容，可能会是这个专栏中最“高冷”的部分，因为这都是从来没有人分享过的内容。 以 lua-nginx-module 这个 OpenResty 中最核心的模块为例，全球一共有 70 多个贡献者，但并非每个贡献者都写过测试案例。所以，如果学完今天的课程，你在 test::nginx 上的理解，绝对可以进入全球 Top 100。
测试中的调试首先，我们来看几个最简单、也是开发者最常用到的原语，它们在平时的调试中会被使用到。下面，我们就来依次介绍下，这几个调试相关的原语的使用场景。
ONLY很多时候，我们都是在原有的测试案例集基础上，新增了一个测试案例。如果这个测试文件包含了很多的测试案例，那么从头到尾跑一遍显然是比较耗时的，这在你需要反复修改测试案例的时候尤为明显。
那么，有没有什么方法只运行你指定的某一个测试案例呢？ ONLY 这个标记可以轻松实现这一点：
=== TEST 1: sanity
=== TEST 2: get
--- ONLY
上面这段伪码就展示了如何使用这个原语。把 --- ONLY 放在需要单独运行的测试案例的最后一行，那么使用 prove 来运行这个测试案例文件的时候，就会忽略其他所有的测试案例，只运行这一个测试了。
不过，这只适合在你做调试的时候使用。所以， prove 命令发现 ONLY 标记的时候，也会给出提示，告诉你不要忘记在提交代码时把它去掉。
SKIP与只执行一个测试案例对应的需求，就是忽略掉某一个测试案例。SKIP 这个标记，一般用于测试尚未实现的功能：
=== TEST 1: sanity
=== TEST 2: get
--- SKIP
从这段伪码你可以看到，它的用法和 ONLY 类似。因为我们是测试驱动开发，需要先编写测试案例；而在集体编码实现时，可能由于实现难度或者优先级的关系，导致某个功能需要延后实现。那么这时候，你就可以先跳过对应的测试案例集，等实现完成后，再把 SKIP 标记去掉即可。
LAST还有一个常用的标记是 LAST，它的用法也很简单，在它之前的测试案例集都会被执行，后面的就会被忽略掉：
=== TEST 1: sanity
=== TEST 2: get
--- LAST
=== TEST 3: set
你可能疑惑，ONLY 和 SKIP 我能理解，但 LAST 这个功能有什么用呢？实际上，有时候你的测试案例是有依赖关系的，需要你执行完前面几个测试案例后，之后的测试才有意义。那么，在这种情况下去调试的话，LAST 就非常有用了。
测试计划 plan在 test::nginx 所有的原语中，plan 是最容易让人抓狂、也是最难理解的一个。它源自于 perl 的 Test::Plan 模块，所以文档并不在 test::nginx中，找到它的解释并不容易，所以我把它放在靠前的位置来介绍。我见过好几个 OpenResty 的代码贡献者，都在这个坑里面跌倒，甚至爬不出来。
下面是一个示例，在 OpenResty 官方测试集的每一个文件的开始部分，你都能看到类似的配置：
plan tests => repeat_each() * (3 * blocks());
这里 plan 的含义是，在整个测试文件中，按照计划应该会做多少次检测项。如果最终运行的结果和计划不符，整个测试就会失败。
拿这个示例来说，如果 repeat_each 的值是 2，一共有 10 个测试案例，那么 plan 的值就应该是 2 x 3 x 10 = 60。这里估计你唯一搞不清楚的，就是数字 3 的含义吧，看上去完全是一个 magic number！
别着急，我们继续看示例，一会儿你就能搞懂了。先来说说，你能算清楚下面这个测试案例中，plan 的正确值是多少吗？
=== TEST 1: sanity
--- config
    location /t {
        content_by_lua_block {
            ngx.say("hello")
        }
    }
--- request
GET /t
--- response_body
hello
我相信所有人都会得出 plan = 1 的结论，因为测试中只对 response_body 进行了校验。
但，事实并非如此！正确的答案是， plan = 2。为什么呢？因为 test::nginx 中隐含了一个校验，也就是--- error_code: 200，它默认检测  HTTP 的 response code 是否为 200。
所以，上面的 magic number 3，真实含义是在每一个测试中都显式地检测了两次，比如 body 和 error log；同时，隐式地检测了 response code。
由于这个地方太容易出错，所以，我的建议是，推荐你用下面的方法，直接关闭掉 plan：
use Test::Nginx::Socket 'no_plan';
如果无法关闭，比如在 OpenResty 的官方测试集中遇到 plan 不准确的情况，建议你也不要去深究原因，直接在 plan 的表达式中增加或者减少数字即可：
plan tests => repeat_each() * (3 * blocks()) + 2;
这也是官方会使用到的方法。
预处理器我们知道，在同一个测试文件的不同测试案例之间，可能会有一些共同的设置。如果在每一个测试案例中都重复设置，就会让代码显得冗余，后面修改起来也比较麻烦。
这时候，你就可以使用 add_block_preprocessor 指令，来增加一段 perl 代码，比如下面这样来写：
add_block_preprocessor(sub {
    my $block = shift;
    if (!defined $block->config) {
        $block->set_value("config", <<'_END_');
    location = /t {
        echo $arg_a;
    }
    _END_
    }
});
这个预处理器，就会为所有的测试案例，都增加一段 config 的配置，而里面的内容就是 location /t。这样，在你后面的测试案例里，就都可以省略掉 config，直接访问即可：
=== TEST 1:
--- request
    GET /t?a=3
--- response_body
3
=== TEST 2:
--- request
    GET /t?a=blah
--- response_body
blah
自定义函数除了在预处理器中增加 perl 代码之外，你还可以在 run_tests 原语之前，随意地增加 perl 函数，也就是我们所说的自定义函数。
下面是一个示例，它增加了一个读取文件的函数，并结合 eval 指令，一起实现了 POST 文件的功能：
sub read_file {
    my $infile = shift;
    open my $in, $infile
        or die "cannot open $infile for reading: $!";
    my $content = do { local $/; <$in> };
    close $in;
    $content;
}
our $CONTENT = read_file("t/test.jpg");
run_tests;
__DATA__
=== TEST 1: sanity
--- request eval
"POST /\n$::CONTENT"
乱序除了上面几点外，test::nginx 还有一个鲜为人知的坑：默认乱序、随机来执行测试案例，而非按照测试案例的前后顺序和编号来执行。
它的初衷是想测试出更多的问题。毕竟，每一个测试案例运行完后，都会关闭 Nginx 进程，并启动新的 Nginx 来执行，结果不应该和顺序相关才对。
对于底层的项目而言，确实如此。但是，对于应用层的项目来说，外部存在数据库等持久化存储。这时候的乱序执行，就会导致错误的结果。由于每次都是随机的，所以可能报错，也可能不报错，每次的报错还可能不同。这显然会给开发者带来困惑，就连我都在这里跌倒过好多次。
所以，我的忠告就是：请关闭掉这个特性。你可以用下面这两行代码来关闭：
no_shuffle();
run_tests;
其中，no_shuffle 原语就是用来禁用随机，让测试严格按照测试案例的前后顺序来运行。
reindex最后，让我们聊一个不烧脑的、轻松一点儿的话题。OpenResty 的测试案例集，对格式有着严格的要求。每个测试案例之间都需要有 3 个换行来分割，测试案例的编号也要严格保持自增长。
幸好，我们有对应的自动化工具 reindex 来做这些繁琐的事情，它隐藏在 [ openresty-devel-utils]  项目中，因为没有文档来介绍，知道的人很少。
有兴趣的同学，可以尝试着把测试案例的编号打乱，或者增删分割的换行个数，然后用这个工具来整理下，看看是否可以还原。
写在最后关于 test::nginx 的介绍就到此结束了。当然，它的功能其实还有更多，我们只讲了最核心最重要的一些。授人以鱼不如授人以渔，学习测试的基本方法和注意点我都已经教给你了，剩下的就需要你自己去官方的测试案例集中去挖掘了。
最后给你留一个问题。在你的项目开发中，是否有测试？你又是使用什么框架来测试的呢？欢迎留言和我交流这个问题，也欢迎你把这篇文章分享给更多的人，一起交流和学习。

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 2

提建议

27 | test::nginx 包罗万象的测试方法

29 | 最容易失准的性能测试？你需要压测工具界的“悍马”wrk

 写留言

精选留言(2)

罐头瓶子
2020-03-30
请问，我有一个接口需要调用两次来做测试，第一次返回和第二次返回的结果要保持一致。我的想法是第一次返回的body需要保存记录下来，第二次请求的body与保存的第一次body做对比。请问我如何保存第一次返回的body?
1
K1
2019-07-29
ssl相关功能用test::nginx是不是测不了？
作者回复: 可以测试的，你可以看下 https://github.com/openresty/lua-nginx-module/blob/master/t 这个目录下面包含 ssl、tls 的测试文件，比如 https://github.com/openresty/lua-nginx-module/blob/master/t/139-ssl-cert-by.t。 OpenResty 会先生成一批测试用的证书，放在 https://github.com/openresty/lua-nginx-module/tree/master/t/cert 目录中，然后在测试案例中使用。

