[注：转载注明：PHP开发资源网(http://bbs.phpres.com/)]

     自从有了面向对象的程序设计方法以来, 测试自动化是程序设计中进步最快的一个方面. 特别是在开发web应用程序时, 即便应用程序复杂, 测试自动化也能保证程序质量. SYMFONY提供了多种工具来实现测试自动化,本章将介绍这些方法.

Automated Tests测试自动化
     任何有经验的web应用程序开发者都很在意要花多少时间来进行完备的测试. 准备和运行测试案例然后分析测试结果是非常费事的工作. 而且, web应用的需求经常变动, 因而一个应用会有一连串的版本, 代码重构成为常事, 从而导致错误不断地产生.

     因而,即使一个成功的开发环境并不要求测试自动化, 我们仍旧提倡测试应该自动化. 一组测试用例可以确保应用程序按照所需要的去执行. 尽管经常会重新设计程序内部结构, 但是测试自动化可以防止重复犯错. 而且, 测试自动化会要求开发者用测试框架能立解的方式书写标准化固定格式的测试用例.

     因为测试自动化能清晰地描述一个应用程序能做些什么, 因而有时侯它可以替代开发文档.一个好的测试包可以揭示出在一组测试输入下应该得到哪些输出结果, 因而可以很好地解释一个方法的运行目标.

     symfony框架将自身就采用了测试自动化.框架内部用测试自动化进行验证,这些单元测试和功能测试并不随symfony一起发布, 但你可以从SVN库或网站http://www.symfony-project.com/trac/browser/trunk/test 得到.

Unit and Functional Tests 单元测试和功能测试

单元测试检测对于一个给定的输入,一段单元代码能否得到正确的输出结果. 它可以对每个具体的测试用例验证函数和方法是否正确执行.单元测试一次处理一个用例, 所以如果一个方法在不同的情况下运行, 就需要多个测试用例.

功能测试不是简单地测试输入输出间的转化是否正确, 而是针对完整的特性.例如, 一个缓存系统只能用一个功能测试去验证, 因为它包括多个运行步骤. 第一次请求一个页面时, 产生缓存数据, 第二次再请求页面时, 页面就直接从缓存中取出.所以, 功能测试可以验证一个运行过程, 同时需要一个运行环境. 你可以用symfony为你的每一个action写出功能测试.

对于最复杂的交互, 这两种测试都不够了.例如, ajax交互, 需要一个web浏览器执行javascript, 所以要自动测试需要一个特殊的第三方工具. 进一步说, 视觉效果的测试必须由人完成.

如果你有多种测试自动化的方法, 你会用到这些方法的组合. 作为一个原则, 你应尽量让测试变得简单而且易于理解.

NOTE Automated tests work by comparing a result with an expected output. In other words, they evaluate assertions (expressions like $a == 2). The value of an assertion is either true or false, and it determines whether a test passes or fails. The word "assertion" is commonly used when dealing with automated testing techniques.注意:测试自动化将测试结果和预期输出进行比较, 也就是说, 它会计算一个象$a==2这样的断言的值. 断言的结果要么是真要么是假, 对应着测试通过或失败. 在测试自动化技术中, 经常会用到断言这个词.

Test-Driven Development 测试驱动的开发

在测试驱动的开发(TDD)方法中, 编码之前就写好了测试用例.先写测试用例可以帮助你在真正开发一个功能之前明确一个功能会完成什么任务. 象极限编程(XP)之类的开发方法也建议这样做.而且一个不可否认的事实是: 如果你不首先写好测试用例, 你就再也写不出来.

例如, 你如果想写一个文本删节的功能, 目的是将字符串开头和末尾的空格清除,用下划线替代非字母字符, 并将所有大写字母转换成小写字母. 在测试驱动的开发中, 你要考虑到所有可能出现的情况, 并对每种情况提供一个输入和预期输出的实例, 如表15-1所示.

表15-1 一个文本删节功能的测试用例表输入        预期输出
" foo "        "foo"
"foo bar"        "foo_bar"
"-)foo:..=bar?"        "__foo____bar_"
"FooBar"        "foobar"
"Don't foo-bar me!"        "don_t_foo_bar_me_"


你要写出单元测试用例, 运行然后看结果是否正确. 你要在代码中添加一些内容来处理第一个测试用例, 运行看是否通过, 再处理第二个测试用例, 一直到所有测试用例都通过, 表明功能正确了.

采用驱动测试的开发方法设计的应用程序, 测试代码几乎和实际代码一样多.因为你不想在调试测试用例方面花费时间,所以要尽力保持测试用例简单.

NOTE Refactoring a method can create new bugs that didn't use to appear before. That's why it is also a good practice to run all automated tests before deploying a new release of an application in production--this is called regression testing.注意 重构一个方法会产生之前没有的错误. 所以在将一个新版应用程序部署到生产环境去之前, 应该运行所有的自动化测试—这叫做回归测试.

The Lime Testing Framework 测试框架

PHP开发领域有许多单元测试框架, 最有名的是PhpUnit和SimpleTest. symfony有自己的测试框架, 叫做lime, 它基于Test::More Perl库, 并且遵守TAP规则, 也就是说, 测试结果按照Test Anything Protocol规定的格式显示, 这样有助于理解测试的输出结果.

lime对单元测试提供支持. 它比许多其他的php测试框架简练, 并且有以下一些优点:
它在一个受限定的环境中运行测试文件, 这样可以避免每次测试之间产生奇怪的副作用.不是所有的测试框架都能保证对每次测试都能提供一个干净的环境.
lim测试用例和测试结果都非常容易理解, 在兼容的系统里, lime用彩色输出这样一来聪明的方法来区分重要信息.
symfony就是利用lime进行回归测试的, 所以在symfony源代码中可以看到许多单元测试和功能测试的例子.
lime核心被单元测试验证过.
lime是用PHP写的, 速度快且经过良好地编码. 它只需一个lime.php文件, 而不依赖于其它任何文件.

以下将使用lime语法描述各种不同的测试, 在symfony安装版本中不包括这些功能.

NOTE Unit and functional tests are not supposed to be launched in production. They are developer tools, and as such, they should be run in the developer's computer, not in the host server.注意 在生产环境中不应该运行单元测试和功能测试. 这些是开发工具, 应该运行在用于开发的机器上, 而不是在实际的服务器上.

Unit Tests 单元测试
symfony单元测试是以Test.php结尾的一些PHP文件, 存放在你的应用程序的test/unit/目录下. 它们采用一种简单易读的语法.

<未完待续，请勿回复，谢谢~~~>

我已经把这部分翻译完了。

具体可见：

[原创中文翻译]Symfony Unit and Functional Testing(Lime)[全文完]

http://www.watir.cn/?p=13