PHPUnit最佳实践来组织测试 [英] PHPUnit best practices to organize tests

查看:158
本文介绍了PHPUnit最佳实践来组织测试的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我目前将从项目的phpunit测试开始.因此,我正在研究某些项目(例如Zend),以了解它们的工作方式以及如何组织测试.

I am currently going to start from scratch with the phpunit tests for a project. So I was looking into some projects (like Zend) to see how they are doing things and how they organizing their tests.

大多数事情都非常清楚,我唯一有问题的是如何正确组织测试套件. Zend有一个AllTests.php,可从中加载其他测试套件.
仔细查看该类,它正在使用PHPUnit_Framework_TestSuite创建一个套件对象,然后向其中添加其他套件,但是如果我查看用于在3.4之后的PHPUnit版本中组织测试的PHPUnit文档,则只有XML或FileHierarchy的描述.使用类来组织测试的一个已删除.
我还没有发现不赞成使用此方法的任何东西,而Zend之类的项目仍在使用它.

Most things are pretty clear, only thing I have some problems with is how to organize the test suites properly. Zend has an AllTests.php from which loads others test suites.
Tough looking at the class it is useing PHPUnit_Framework_TestSuite to create a suite object and then add the other suites to it, but if I look in the PHPUnit docs for organizing tests in PHPUnit versions after 3.4 there is only a description for XML or FileHierarchy. The one using classes to organize the tests was removed.
I haven't found anything that this method is deprecated and projects like Zend are still using it.

但是,如果不赞成使用它,我如何能够以与xml配置相同的结构来组织测试?执行所有测试都没问题,但是如果我只想执行几个测试,我将如何组织这些测试(在xml中).也许在我仅指定要运行的几个测试/测试套件的情况下创建几个xml?

But if it is deprecated, how would I be able to organize tests in the same structure with the xml configuration? Executing all tests is no problem, but how would I organize the tests (in the xml) if I only wanted to execute a few tests. Maybe creating several xmls where I only specify a few tests/test suites to be run?

因此,如果我只想测试应用程序的module1和module2,我将为每个模块提供一个额外的xml,并为其中的那些模块(模块使用的类)定义测试套件.还有为所有测试定义测试套件的工具吗?

So if I would want to only test module1 and module2 of the application, would I have an extra xml for each and defining test suites only for those modules (classes used by the module) in it. And also one that defines a test suite for all tests?

还是在特定测试上使用@group注释将它们标记为用于module1或module2更好?

Or would it be better to use the @group annotation on the specific tests to mark them to be for module1 or module2?

在此先感谢您向我介绍一些最佳做法.

Thanks in advance for pointing me to some best practices.

推荐答案

我将从链接到手册开始,然后进入我在实地所见所闻.

I'll start of by linking to the manual and then going into what I've seen and heard in the field.

组织phpunit测试套件

我推荐的方法是将文件系统与xml配置结合起来.

My recommended approach is combining the file system with an xml config.

tests/
 \ unit/
 | - module1
 | - module2
 - integration/
 - functional/

带有phpunit.xml并带有简单的符号:

with a phpunit.xml with a simple:

<testsuites>
  <testsuite name="My whole project">
    <directory>tests</directory>
  </testsuite>
</testsuites>

如果需要,您可以拆分测试套件,但这就是一个项目,一个项目一个.

you can split the testsuites if you want to but thats a project to project choice.

运行phpunit然后将执行所有测试,运行phpunit tests/unit/module1将运行module1的所有测试.

Running phpunit will then execute ALL tests and running phpunit tests/unit/module1 will run all tests of module1.

这里最常用的方法是将source/目录结构镜像到tests/unit/文件夹结构中.

The most common approach here is to mirror your source/ directory structure in your tests/unit/ folder structure.

无论如何,每个ProductionClass都有一个TestClass,所以这是我的书中的一种好方法.

You have one TestClass per ProductionClass anyways so it's a good approach in my book.

  • 每个文件一个类.

如果一个文件中有多个测试类,则无论如何都无法正常工作,因此请避免这种陷阱.

It's not going to work anyways if you have more than one test class in one file so avoid that pitfall.

  • 没有测试名称空间

由于您需要一条附加的use语句,这只会使测试的编写变得更加冗长,因此我想说testClass应该与生产类使用相同的名称空间,但这并不是PHPUnit强迫您执行的.我刚刚发现它更简单,没有缺点.

It just makes writing the test more verbose as you need an additional use statement so I'd say the testClass should go in the same namespace as the production class but that is nothing PHPUnit forces you to do. I've just found it to be easier with no drawbacks.

例如,phpunit --filter Factory执行所有FactoryTest,而phpunit tests/unit/logger/执行所有与日志记录相关的内容.

For example phpunit --filter Factory executes all FactoryTests while phpunit tests/unit/logger/ executes everything logging related.

对于问题编号,故事或其他内容,您可以使用@group标记,但对于模块",我将使用文件夹布局.

You can use @group tags for something like issue numbers, stories or something but for "modules" I'd use the folder layout.

如果要创建多个xml文件,可能会很有用:

It can be useful to create multiple xml files if you want to have:

  • 一个没有代码覆盖的人
  • 仅用于单元测试(但不用于功能或集成或长期运行的测试)
  • 其他常见的过滤器"案例
  • 例如,
  • PHPBB3可以做到 their phpunit.xmls
  • one without code coverage
  • one just for the unit tests (but not for the functional or integration or long running tests)
  • other common "filter" cases
  • PHPBB3 for example does that for their phpunit.xmls

与通过测试开始新项目有关:

As it is related to starting a new project with tests:

  • 我的建议是使用@covers标记我的博客(仅用于单元测试,始终涵盖所有非公共功能,始终使用Covers标签.
  • 不为您的集成测试提供保障.它给您一种错误的安全感.
  • 始终使用白名单来包括您所有的生产代码,这样数字就不会骗您了!
  • My suggestion is to use @covers tags like described in my blog (Only for unit tests, always cover all non public functions, always use covers tags.
  • Don't generate coverage for your integration tests. It gives you a false sense of security.
  • Always use whitelisting to include all of your production code so the numbers don't lie to you!

您不需要任何类型的自动加载即可进行测试. PHPUnit会解决这个问题.

You don't need any sort of auto loading for your tests. PHPUnit will take care of that.

使用<phpunit bootstrap="file">属性指定测试引导程序. tests/bootstrap.php是放置它的好地方.在那里,您可以设置应用程序自动加载器等(或为此而调用应用程序引导程序).

Use the <phpunit bootstrap="file"> attribute to specify your test bootstrap. tests/bootstrap.php is a nice place to put it. There you can set up your applications autoloader and so on (or call your applications bootstrap for that matter).

  • 几乎所有内容都使用xml配置
  • 单独的单元和集成测试
  • 您的单元测试文件夹应反映您的应用程序文件夹结构
  • 仅执行指定测试,请使用phpunit --filterphpunit tests/unit/module1
  • 从一开始就使用 strict 模式,切勿将其关闭.
  • Use the xml configuration for pretty much everything
  • Seperate unit and integration tests
  • Your unit test folders should mirror your applications folder structure
  • To only execute specif tests use phpunit --filter or phpunit tests/unit/module1
  • Use the strict mode from the get go and never turn it off.
  • Sebastian Bergmanns "Bank Account" example project
  • phpBB3 Even so they have to fight some with their legacy ;)
  • Symfony2
  • Doctrine2

这篇关于PHPUnit最佳实践来组织测试的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆