本页面描述了一些最有用的 Angular 测试特性。
Angular 测试实用工具包括 TestBed
、ComponentFixture
以及一些控制测试环境的函数。TestBed
和 ComponentFixture
类是单独介绍的。
下面是一些独立函数的摘要,以使用频率排序:
函数 | 详情 |
---|---|
| 在一个特殊的async 测试区域中运行测试( |
| 在一个特殊的fakeAsync 测试区域中运行测试( |
| 通过在 fakeAsync 测试区域中刷新定时器和微任务(micro-task)队列来仿真时间的流逝以及异步活动的完成。 好奇和执着的读者可能会喜欢这篇长博客: 接受一个可选参数,它可以把虚拟时钟往前推进特定的微秒数。清除调度到那个时间帧中的异步活动。 |
| 从当前的 TestBed 注入器中把一个或多个服务注入到一个测试函数中。它不能用于注入组件自身提供的服务。 |
| 当 fakeAsync 测试程序以正在运行的计时器事件任务(排队中的 setTimeOut 和 setInterval 的回调)结束时,测试会失败,并显示一条明确的错误信息。一般来讲,测试程序应该以无排队任务结束。当待执行计时器任务存在时,调用 discardPeriodicTasks 来触发任务队列,防止该错误发生。 |
| 当 一般来说,测试应该等待微任务结束。当待执行微任务存在时,调用 |
| 一个服务提供者令牌,用于开启自动变更检测。 |
| 获取当前 TestBed 实例。通常用不上,因为 TestBed 的静态类方法已经够用。TestBed 实例有一些很少需要用到的方法,它们没有对应的静态方法。 |
TestBed
类是 Angular 测试工具的主要类之一。它的 API 很庞大,可能有点过于复杂,直到你一点一点的探索它们。
传给 configureTestingModule
的模块定义是 @NgModule
元数据属性的子集。
type TestModuleMetadata = {
providers?: any[];
declarations?: any[];
imports?: any[];
schemas?: Array<SchemaMetadata | any[]>;
};
每一个重载方法接受一个 MetadataOverride<T>
,这里 T
是适合这个方法的元数据类型,也就是 @NgModule
、@Component
、@Directive
或者 @Pipe
的参数。
type MetadataOverride<T> = {
add?: Partial<T>;
remove?: Partial<T>;
set?: Partial<T>;
};
TestBed
的 API 包含了一系列静态类方法,它们更新或者引用全局的 TestBed
实例。
在内部,所有静态方法在 getTestBed()
函数返回的当前运行时间的 TestBed
实例上都有对应的方法。
在 BeforeEach()
内调用 TestBed
方法,以确保在运行每个单独测试时,都有崭新的开始。
这里列出了最重要的静态方法,以使用频率排序。
方法 | 详情 |
---|---|
| 测试垫片( |
| 在配置好测试模块之后,异步编译它。如果测试模块中的任何一个组件具有 |
| 基于当前 |
| 替换指定的 |
| 替换指定组件类的元数据,该组件类可能嵌套在一个很深的内部模块中。 |
| 替换指定指令类的元数据,该指令可能嵌套在一个很深的内部模块中。 |
| 替换指定管道类的元数据,该管道可能嵌套在一个很深的内部模块中。 |
| 从当前 expect(TestBed.inject(NotProvided, null)).toBeNull();调用了 TestBed.inject 之后然后通过调用,TestBed 的配置就会在当前测试期间被冻结。 |
| 为整套测试的运行初始化测试环境。 |
| 重设初始测试环境,包括默认测试模块在内。 |
少数 TestBed
实例方法没有对应的静态方法。它们很少被使用。
TestBed.createComponent<T>
会创建一个组件 T
的实例,并为该组件返回一个强类型的 ComponentFixture
。
ComponentFixture
的属性和方法提供了对组件、它的 DOM 和它的 Angular 环境方面的访问。
下面是对测试最重要的属性,以使用频率排序。
属性 | 详情 |
---|---|
| 被 |
| 与组件根元素关联的 |
| 组件的原生根 DOM 元素。 |
| 组件的 |
fixture 方法使 Angular 对组件树执行某些任务。在触发 Angular 行为来模拟的用户行为时,调用这些方法。
下面是对测试最有用的方法。
方法 | 详情 |
---|---|
| 为组件触发一轮变化检查。 |
| 如果你希望这个夹具自动检测变更,就把这个设置为 |
| 运行一次变更检测来确认没有待处理的变化。如果有未处理的变化,它将抛出一个错误。 |
| 如果 fixture 当前是稳定的,则返回 |
| 返回一个承诺,在 fixture 稳定时解析。 |
| 触发组件的销毁。 |
DebugElement
提供了对组件的 DOM 的访问。
fixture.debugElement
返回测试根组件的 DebugElement
,通过它你可以访问(查询)fixture 的整个元素和组件子树。
下面是 DebugElement
最有用的成员,以使用频率排序。
成员 | 详情 |
---|---|
| 与浏览器中 DOM 元素对应(WebWorkers 时,值为 null)。 |
| 调用 |
| 调用 |
| 宿主依赖注入器。比如,根元素的组件实例注入器。 |
| 元素自己的组件实例(如果有)。 |
| 为元素提供父级上下文的对象。通常是控制该元素的祖级组件实例。 |
|
|
|
|
| 元素的标签名字,如果它是一个元素的话。 |
| 如果在该元素的 |
| 元素的 |
| 组件注入器的查询令牌。包括组件自己的令牌和组件的 |
| source 是在源组件模板中查询这个元素的处所。 |
| 与模板本地变量(比如 |
DebugElement.query(predicate)
和 DebugElement.queryAll(predicate)
方法接受一个条件方法,它过滤源元素的子树,返回匹配的 DebugElement
。
这个条件方法是任何接受一个 DebugElement
并返回真值的方法。下面的例子查询所有拥有名为 content
的模块本地变量的所有 DebugElement
:
// Filter for DebugElements with a #content reference
const contentRefs = el.queryAll( de => de.references['content']);
Angular 的 By
类为常用条件方法提供了三个静态方法:
静态方法 | 详情 |
---|---|
By.all | 返回所有元素 |
By.css(selector) | 返回符合 CSS 选择器的元素 |
By.directive(directive) | 返回 Angular 能匹配一个指令类实例的所有元素 |
// Can find DebugElement either by css selector or by directive
const h2 = fixture.debugElement.query(By.css('h2'));
const directive = fixture.debugElement.query(By.directive(HighlightDirective));