예배 규칙서 찾다
阅读前篇 简介 Yii 是什么 从 Yii 1.1 升级 入门 安装 Yii 运行应用 第一次问候 使用Forms 数据库应用 使用 Gii 生成代码 进阶 应用结构 概述 入口脚本 应用(Applications) 应用组件(Application Components) 控制器(Controllers) 模型(Models) 视图(views) 模块(Modules) 过滤器(Filters) 小部件(Widgets) 前端资源(Assets) 扩展(Extensions) 请求处理 运行概述 启动引导(Bootstrapping) 路由和创建URL 请求(Requests) 响应(Responses) Sessions 和 Cookies 错误处理(Handling Errors) 日志(Logging) 关键概念 组件(Component) 属性(Property) 事件(Events) 行为(Behaviors) 配置(Configurations) 别名(Aliases) 类自动加载(Autoloading) 服务定位器(Service Locator) 依赖注入容器(Dependency Injection Container) 配合数据库工作 数据库访问 (Data Access Objects) 查询生成器(Query Builder) 活动记录(Active Record) 数据库迁移(Migrations) Sphinx Redis MongoDB Elasticsearch 接收用户数据 创建表单(Creating Forms) 输入验证(Validating Input) 文件上传(Uploading Files) 收集列表输入(Collecting Tabular Input) 多模型的复合表单(Getting Data for Multiple Models) 显示数据 格式化输出数据(Data Formatting) 分页(Pagination) 排序(Sorting) 数据提供器(Data Providers) 数据小部件(Data Widgets) 客户端脚本使用(Working with Client Scripts) 主题(Theming) 安全 认证(Authentication) 授权(Authorization) 处理密码(Working with Passwords) 客户端认证(Auth Clients) 最佳安全实践(Best Practices) 缓存 概述 数据缓存 片段缓存 页面缓存 HTTP 缓存 RESTfull Web服务 快速入门(Quick Start) 资源(Resources) 控制器(Controllers) 路由(Routing) 格式化响应(Response Formatting) 授权认证(Authentication) 速率限制(Rate Limiting) 版本(Versioning) 错误处理(Error Handling) 开发工具 调试工具栏和调试器 使用Gii生成代码 生成API文档 测试 概述(Overview) 配置测试环境(Testing environment setup) 单元测试(Unit Tests) 功能测试(Function Tests) 验收测试(Acceptance Tests) 测试夹具(Fixtures) 高级专题 高级应用模板 创建自定义应用程序结构 控制台命令 核心验证器(Core Validators) 国际化 收发邮件 性能优化 共享主机环境 模板引擎 集成第三方代码 小部件 Bootstrap 小部件 Jquery UI 助手类 概述 Array 助手(ArrayHelper) Html 助手(Html) Url 助手(Url)
문자

概述

测试

测试是软件开发的一个重要组成部分。不管我们是否意识到,我们一直在不断地进行测试。 例如,当我们在用 PHP 写一个类的时候,我们可能用 echo 或者 die 语句一步一步简单的调试 验证我们实现的代码是否按照最初的计划工作。在开发 web 应用的时候,我们在表单中输入 一些测试数据来确保页面能够如预期那样和我们进行交互。

测试过程可能是自动的,所以每次我们需要验证的时候,我们只需要调用它就可以测试代码 了。 验证代码执行结果是否符合我们的计划叫做测试,测试过程的创建以及进一步执行叫做 自动化测试,这是这些测试章节的主要主题。

带着测试进行开发

测试驱动开发(TDD)和行为驱动开发(BDD)在开始编写实际代码之前,首先通过描述一段 代码的行为或将其作为一组场景或测试的全部特征,然后创建符合这些测试预期验证的行为 实现。

开发一个功能的过程如下:

  • 创建一个描述一个功能被实现测试。
  • 运行这个测试来确保功能失败.因为这是没有实现之前的预期。
  • 编写简单代码确保这个测试通过。
  • 运行所有测试确保所有测试都通过。
  • 优化代码确保测试依然可以通过。

走完上面的过程之后,为其他功能或者扩展重复上面测试过程。如果功能发生变化,测试也需 要跟着变化。

技巧: 如果你觉得你做一些很小很简单的迭代是在浪费时间,请尝试覆盖更多的测试 场景,这样你就可以在执行测试之前做更多的尝试。如果你的调试过多,试着做相反的工作。

在做一些具体的实现之前创建测试的原因是,这允许我们后期专注于我们想要的实现,并且 可以花费更多的精力到实现细节。在涉及功能调整的时候,这会使得抽象更合理、测试维护 更简单或者使得耦合元件更少。

这种做法的优点如下:

  • 在计划和实现发生变更的时候,可以让你在同一时间只专注于一件事情。
  • 更多功能更详细的覆盖测试的结果,如果测试都通过好比再也没有什么问题了。

在很长一段时间内,这通常会给你提供一个有效的时间节省。

技巧: 如果你想了解更多关于收集软件需求和建模的原则,最好去学习 Domain Driven Development (DDD)。

什么时候测试,怎么测试?

在测试的时候,对于一些相对复杂的项目上面的内容是非常有意义的,但对于一些比较 简单的项目就做的有些极端了。适用场景如下:

  • 项目已经很大且复杂。
  • 项目需求开始变得复杂起来。项目不断发展。
  • 项目历时很长。
  • 失败的代价非常高。

在现有的实现行为中进行覆盖测试是非常适合的。

  • 项目是一个逐步更新的遗产。
  • 你有一个还没有经过测试的项目要做。

在一些情况下,任何形式的自动化测试都是过于极端的:

  • 项目很简单,也不会变得复杂。
  • 过期不再工作的一次性项目。

假如你有很多的时间,在这种情况下进行自动测试也很好。

深度阅读

  • Test Driven Development: By Example / Kent Beck. ISBN: 0321146530.
이전 기사: 다음 기사: