首先,我会链接到手册,然后详细介绍我在实地工作中所见所闻。
组织phpunit测试套件
文件系统中的模块/测试文件夹组织
我推荐的方法是将文件系统与xml配置相结合。
tests/
\ unit/
| - module1
| - module2
- integration/
- functional/
使用一个简单的
phpunit.xml
。
<testsuites>
<testsuite name="My whole project">
<directory>tests</directory>
</testsuite>
</testsuites>
如果你想的话,你可以分割测试套件,但这是一个项目选择。
运行phpunit
将执行所有测试,而运行phpunit tests/unit/module1
将运行module1的所有测试。
"unit"文件夹的组织
这里最常见的方法是在tests/unit/
文件夹结构中反映出你的source/
目录结构。
无论如何,每个ProductionClass都有一个TestClass,所以这是我认为的一个好方法。
文件组织
如果一个文件中有多个测试类,那么它不会起作用,所以要避免这个陷阱。
这只会使编写测试更冗长,因为你需要额外的use语句,所以我认为测试类应该与生产类在同一个命名空间中,但这并不是PHPUnit强制要求你做的。我发现这样做更容易且没有任何缺点。
只执行几个测试
例如,
phpunit --filter Factory
执行所有 FactoryTests,而
phpunit tests/unit/logger/
执行与日志相关的所有内容。
您可以使用
@group
标签来标记问题编号、故事或其他内容,但对于“模块”,我会使用文件夹布局。
多个 XML 文件
如果您想要拥有以下内容,创建多个 XML 文件可能会很有用:
- 一个没有代码覆盖率的文件
- 一个仅用于单元测试(而不是功能测试、集成测试或长时间运行的测试)的文件
- 其他常见的“过滤”情况
- 例如,PHPBB3 就是这样做的
他们的 phpunit.xmls
为您的测试添加代码覆盖率
由于这与启动一个新项目并进行测试相关:
- 我的建议是使用
@covers
标签,就像我在博客中描述的那样(仅适用于单元测试,始终覆盖所有非公共函数,始终使用covers标签)。
- 不要为集成测试生成覆盖率报告,这会给你一种虚假的安全感。
- 始终使用白名单来包含所有生产代码,这样数据才不会欺骗你!
自动加载和启动测试
你的测试不需要任何形式的自动加载。PHPUnit会处理这个问题。
使用<phpunit bootstrap="file">
属性来指定你的测试引导文件。将其放在tests/bootstrap.php
是一个不错的选择。在那里,你可以设置应用程序的自动加载器等(或者调用应用程序的引导文件)。
总结
- 几乎所有的东西都要使用xml配置
- 分离单元测试和集成测试
- 你的单元测试文件夹应该与应用程序的文件夹结构相对应
- 要只执行特定的测试,请使用
phpunit --filter
或phpunit tests/unit/module1
- 从一开始就使用
strict
模式,并且永远不要关闭它。
可以参考的示例项目