昨天我们知道了如何选择性测试某些测试元
今天继续往下学
Tests Organization
)今天来说下两个概念,集成测试(integration tests
)和单元测试(unit tests
)。
Unit Test
)其实我们之前学的全都是单元测试,是直接写在每一个文件(src
文件夹下)里的。
还记得之前的例子中使用的#[cfg(test)]
[3]吗?
这就是在声明一个测试模块,它们不会占用你编译的时间和空间,只有你在开发时执行cargo test
时他们才会被转换成binary
然后执行,而使用run/build
输出的代码中是没有测试相关代码的。
cfg
是一个attribute
,之前我们见过的attribute
还有derive
。
cfg
是configuration
的缩写。 而test
是configuration
这个attribute
的option
也就是选项。
大家应该都很熟悉了。
当然,你的测试函数必须注释#[test]
,不然也是不会执行的。
另外在rust
中要测试私有方法[4]等会比其他语言简单些(当然,不包括js
:我想怎么用就这么用,什么?闭包里的方法?打扰了)。
我们直接来看下例子
由于是在同一个文件中,我们直接super
一下就好了。
Integration test
)和单元测试相反,集成测试得放在library
之外,也就是说它们调用你的library
和这个库被别的project
直接引用一样。另外它是全部测试的,也就是说单元测试是对的并不意味着集成测试也是对的,所以集成测试是必不可少的。
我们来创建一个tests
的文件夹,和src
同级。cargo
默认会去这个tests
文件夹找测试块。tests
文件夹里的每一个test
文件都会被编译成单独的crate
。
我们再tests
文件夹下创建一个名为integration_test.rs
的文件,在里面调用lib.rs
里的method
。
由于每一个test
文件都是一个crate
,所以引用外部的crate
都得使用use
将它们导入先(prelude
的另说)。
adder
是我们的包名字,之前有说过,如果是调用库的话,路径得从包名开始。而且由于lib.rs
是默认library
文件,所以并不需要adder::lib::add_two
这样调用。
另外我们也不需要去注释#[cfg(test)]
,因为都已经移出来了。
测试正常,然后我把刚才注释掉的unit test
代码注释回来,再test
一次
可以看到都被执行了。它里面包含了三部分,单元测试、集成测试和文档测试,不过我们的代码里没有文档测试相关的。
有一点需要注意的是,如果其中一种fail
了之后,后续的就都不会执行了。比如在单元测试中fail
了,那么集成测试中是不会运行的
如果只是想测试某个test
文件,我们可以直接在终端输入
另外,如果你有文件是放在tests
文件夹里的,但是这里面放的都不是测试用代码,而是一些helper
,它们默认也会被当做tests
文件编译。
rust
官方也是考虑到了这个问题。[6]
我们先在tests
文件夹里新建一个common.rs
文件,然后搞个setup
方法。
可以看到他也被编译进去了,这不是我们想要的。
为了避免这种情况,我们得把common.rs
改成common/mod.rs
这样就避开了。
之前学packages/module/crate
的时候有说过,rust
查找module
的时候的规律,其中有一个就是xxx/mod.rs
,比如下面的例子
我们用的common
这个mod
,就是根据tests/common/mod.rs
查找规则找到的。
最后说一下如果项目里只有binary crate
,不包含library crate
,那么你这个项目是不能创建test
的。
binary crate
的代码意味着只能是binary
自己使用,所以它们的代码并不需要test
,有需要则自行抽离公共方法放到lib
中。这也算是一种好的开发约束吧。
我们现在学会了如何创建test
包括集成测试和单元测试。
这一章是比较轻松的。
最后,如果这篇文章对你有帮助的话,请务必点个赞,谢谢~
发布于 2022-12-20 22:52・IP 属地广东