translate: testing is done.

This commit is contained in:
rexebin 2016-10-18 21:48:48 +01:00
parent 9d9b00b3b9
commit f8b80ad3e5

View File

@ -3452,165 +3452,270 @@ table
A few of the `TestBed` instance methods are not covered by static `TestBed` _class_ methods.
These are rarely needed.
少数`TestBed`实例方法没有对应的静态方法。它们很少被使用。
#component-fixture-api-summary
:marked
## The _ComponentFixture_
## _ComponentFixture_
The `TestBed.createComponent<T>`
creates an instance of the component `T`
and returns a strongly typed `ComponentFixture` for that component.
`TestBed.createComponent<T>`创建一个组件`T`的实例,并为该组件返回一个强类型的`ComponentFixture`。
The `ComponentFixture` properties and methods provide access to the component,
its DOM representation, and aspects of its Angular environment.
`ComponentFixture`的属性和方法提供了对组件、它的DOM和它的Angular环境方面的访问。
#component-fixture-properties
:marked
### _ComponentFixture_ properties
### _ComponentFixture_ 属性
Here are the most important properties for testers, in order of likely utility.
下面是对测试最重要的属性,以使用频率排序:
table
tr
th Properties
th Description
th
:marked
Properties
属性
th
:marked
Description
描述
tr
td(style="vertical-align: top") <code>componentInstance</code>
td
:marked
The instance of the component class created by `TestBed.createComponent`.
被`TestBed.createComponent`创建的组件类实例。
tr
td(style="vertical-align: top") <code>debugElement</code>
td
:marked
The `DebugElement` associated with the root element of the component.
与组件根元素关联的`DebugElement`。
The `debugElement` provides insight into the component and its DOM element during test and debugging.
It's a critical property for testers. The most interesting members are covered [below](#debug-element-details).
`debugElement`在测试和调试期间提供对组件及其DOM元素的访问。
它是测试者至关重要的属性。它最有用的成员在[下面](#debug-element-details)有所介绍。
tr
td(style="vertical-align: top") <code>nativeElement</code>
td
:marked
The native DOM element at the root of the component.
组件的原生根DOM元素。
tr
td(style="vertical-align: top") <code>changeDetectorRef</code>
td
:marked
The `ChangeDetectorRef` for the component.
组件的`ChangeDetectorRef`。
The `ChangeDetectorRef` is most valuable when testing a
component that has the `ChangeDetectionStrategy.OnPush`
or the component's change detection is under your programmatic control.
在测试一个拥有`ChangeDetectionStrategy.OnPush`的组件,或者在组件的变化测试在你的程序控制下时,`ChangeDetectorRef`是最重要的。
#component-fixture-methods
:marked
### _ComponentFixture_ methods
### _ComponentFixture_方法
The _fixture_ methods cause Angular to perform certain tasks to the component tree.
Call these method to trigger Angular behavior in response to simulated user action.
**fixture**方法使组件对组件树执行某些任务。
调用此方法来触发针对模拟的用户行为作出的Angular行为。
Here are the most useful methods for testers.
下面使对测试最有用的方法。
table
tr
th Methods
th Description
th
:marked
Methods
方法
th
:marked
Description
描述
tr
td(style="vertical-align: top") <code>detectChanges</code>
td
:marked
Trigger a change detection cycle for the component.
为组件触发一轮变化检查。
Call it to initialize the component (it calls `ngOnInit`) and after your
test code change the component's data bound property values.
Angular can't see that you've changed `personComponent.name` and won't update the `name`
binding until you call `detectChanges`.
调用它来初始化组件(它调用`ngOnInit`)。或者在你的测试代码改变了组件的数据绑定属性值后调用它。
Angular不能检测到你已经改变了`personComponent.name`属性,也不会更新`name`的绑定,直到你调用了`detectChanges`。
Runs `checkNoChanges`afterwards to confirm there are no circular updates unless
called as `detectChanges(false)`;
之后,运行`checkNoChanges`,来确认没有循环更新,除非它被这样调用:`detectChanges(false)`。
tr
td(style="vertical-align: top") <code>autoDetectChanges</code>
td
:marked
Set whether the fixture should try to detect changes automatically.
设置fixture是否应该自动试图检测变化。
When autodetect is true, the test fixture listens for _zone_ events and calls `detectChanges`.
You probably still have to call `fixture.detectChanges` to trigger data binding updates
when your test code modifies component property values directly.
当自动检测打开时测试fixture监听**zone**事件,并调用`detectChanges`。
当你的测试代码直接修改了组件属性值时,你还是要调用`fixture.detectChanges`来触发数据绑定更新。
The default is `false` and testers who prefer fine control over test behavior
tend to keep it `false`.
默认值是`false`,喜欢对测试行为进行精细控制的测试者一般保持它为`false`。
Calls `detectChanges` immediately which detects existing changes
and will trigger `ngOnInit` if the component has not yet been initialized.
如果组件还没有被初始化,立刻调用`detectChanges`将检测已有变化并触发`ngOnInit`。
tr
td(style="vertical-align: top") <code>checkNoChanges</code>
td
:marked
Do a change detection run to make sure there are no pending changes.
Throws an exceptions if there are.
运行一次变化检测来确认没有待处理的变化。如果有未处理的变化,它将抛出一个错误。
tr
td(style="vertical-align: top") <code>isStable</code>
td
:marked
Return `true` if the fixture is currently _stable_.
Returns `false` if there are async tasks that have not completed.
如果fixture当前是**稳定的**,则返回`true`。
如果有异步任务没有完成,则返回`false`。
tr
td(style="vertical-align: top") <code>whenStable</code>
td
:marked
Returns a promise that resolves when the fixture is stable.
返回一个承诺在fixture稳定时解析。
Hook that promise to resume testing after completion of asynchronous activity or
asynchronous change detection.
See [above](#when-stable)
勾住这个承诺,以在异步行为或者异步变化检测之后继续测试。
参见[上面](#when-stable)
tr
td(style="vertical-align: top") <code>destroy</code>
td
:marked
Trigger component destruction.
触发组件的销毁。
#debug-element-details
:marked
### _DebugElement_
### _DebugElement_
The `DebugElement` provides crucial insights into the component's DOM representation.
`DebugElement`提供了对组件的DOM提供了访问渠道。
From the test root component's `DebugElement`, returned by `fixture.debugElement`,
you can walk (and query) the fixture's entire element and component sub-trees.
`fixture.debugElement`返回测试根组件的`DebugElement`通过它你可以访问查询fixture的整个元素和组件子树。
Here are the most useful `DebugElement` members for testers in approximate order of utility.
下面是`DebugElement`最有用的成员,以使用频率排序。
table
tr
th Member
th Description
th
:marked
Members
成员
th
:marked
Description
描述
tr
td(style="vertical-align: top") <code>nativeElement</code>
td
:marked
The corresponding DOM element in the browser (null for WebWorkers).
与浏览器中DOM元素对应WebWorkers时值为null
tr
td(style="vertical-align: top") <code>query</code>
td
:marked
Calling `query(predicate: Predicate<DebugElement>)` returns the first `DebugElement`
that matches the [predicate](#query-predicate) at any depth in the subtree.
调用`query(predicate: Predicate<DebugElement>)`返回第一个`DebugElement`
它在子树所有层中匹配[predicate](#query-predicate)。
tr
td(style="vertical-align: top") <code>queryAll</code>
td
:marked
Calling `queryAll(predicate: Predicate<DebugElement>)` returns all `DebugElements`
that matches the [predicate](#query-predicate) at any depth in subtree.
调用`query(predicate: Predicate<DebugElement>)`返回所有`DebugElement`
它在子树所有层中匹配[predicate](#query-predicate)。
tr
td(style="vertical-align: top") <code>injector</code>
td
:marked
The host dependency injector.
For example, the root element's component instance injector.
宿主依赖注入器。
比如,根元素的组件实例注入器。
tr
td(style="vertical-align: top") <code>componentInstance</code>
td
:marked
The element's own component instance, if it has one.
元素自己的组件实例(如果有)。
tr
td(style="vertical-align: top") <code>context</code>
td
@ -3618,32 +3723,47 @@ table
An object that provides parent context for this element.
Often an ancestor component instance that governs this element.
为元素提供父级上下文的对象。
通常是控制该元素的祖级组件实例。
When an element is repeated with in `*ngFor`, the context is an `NgForRow` whose `$implicit`
property is the value of the row instance value.
For example, the `hero` in `*ngFor="let hero of heroes"`.
当一个元素被`*ngFor`重复,它的上下文为`NgForRow`,它的`$implicit`属性值是该行的实例值。
比如,`*ngFor="let hero of heroes"`里的`hero`。
tr
td(style="vertical-align: top") <code>children</code>
td
:marked
The immediate `DebugElement` children. Walk the tree by descending through `children`.
`DebugElement`的直接子级。通过`children`来降序探索元素树。
.l-sub-section
:marked
`DebugElement` also has `childNodes`, a list of `DebugNode` objects.
`DebugElement` derives from `DebugNode` objects and there are often
more nodes than elements. Testers can usually ignore plain nodes.
`DebugElement`还有`childNodes`,即`DebugNode`对象列表。
`DebugElement`从`DebugNode`对象衍生而且通常节点node比元素多。测试者通常忽略赤裸节点。
tr
td(style="vertical-align: top") <code>parent</code>
td
:marked
The `DebugElement` parent. Null if this is the root element.
`DebugElement`的父级。如果它是根元素则为null。
tr
td(style="vertical-align: top") <code>name</code>
td
:marked
The element tag name, if it is an element.
元素的标签名字,如果它是一个元素的话。
tr
td(style="vertical-align: top") <code>triggerEventHandler</code>
td
@ -3653,27 +3773,40 @@ table
The second parameter is the _event object_ expected by the handler.
See [above](#trigger-event-handler).
如果在元素的`listeners`列表中有一个对应的`listener`,则以事件名字触发。
第二个参数是**事件对象**,一般为事件处理器。
参见[上面](#trigger-event-handler)。
If the event lacks a listener or there's some other problem,
consider calling `nativeElement.dispatchEvent(eventObject)`
如果事件缺乏监听器,或者有其它问题,考虑调用`nativeElement.dispatchEvent(eventObject)`。
tr
td(style="vertical-align: top") <code>listeners</code>
td
:marked
The callbacks attached to the component's `@Output` properties and/or the element's event properties.
元素的`@Output`属性以及/或者元素的事件属性所附带的回调函数。
tr
td(style="vertical-align: top") <code>providerTokens</code>
td
:marked
This component's injector lookup tokens.
Includes the component itself plus the tokens that the component lists in its `providers` metadata.
组件注入器的查询令牌。
包括组件自己的令牌和组件的`providers`元数据中列出来的令牌。
tr
td(style="vertical-align: top") <code>source</code>
td
:marked
Where to find this element in the source component template.
source是在源组件模板中查询这个元素的处所。
tr
td(style="vertical-align: top") <code>references</code>
td
@ -3681,20 +3814,39 @@ table
Dictionary of objects associated with template local variables (e.g. `#foo`),
keyed by the local variable name.
与模板本地变量(比如`#foo`)关联的词典对象,关键字与本地变量名字配对。
#query-predicate
:marked
The `DebugElement.query(predicate)` and `DebugElement.queryAll(predicate)` methods take a
predicate that filters the source element's subtree for matching `DebugElement`.
`DebugElement.query(predicate)`和`DebugElement.queryAll(predicate)`方法接受一个条件方法,
它过滤源元素的子树,返回匹配的`DebugElement`。
The predicate is any method that takes a `DebugElement` and returns a _truthy_ value.
The following example finds all `DebugElements` with a reference to a template local variable named "content":
这个条件方法是任何接受一个`DebugElement`并返回真值的方法。
下面的例子查询所有拥有名为`content`的模块本地变量的所有`DebugElement`
+makeExample('testing/ts/app/bag/bag.spec.ts', 'custom-predicate')(format=".")
:marked
The Angular `By` class has three static methods for common predicates:
Angular的`By`类为常用条件方法提供了三个静态方法:
* `By.all` - return all elements
* `By.all` - 返回所有元素
* `By.css(selector)` - return elements with matching CSS selectors.
* `By.directive(directive)` - return elements that Angular matched to an instance of the directive class.
* `By.css(selector)` - 返回符合CSS选择器的元素。
* `By.directive(directive)` - return elements that Angular matched to an instance of the directive class.
* `By.directive(directive)` - 返回Angular能匹配一个指令类实例的所有元素。
+makeExample('testing/ts/app/hero/hero-list.component.spec.ts', 'by', 'app/hero/hero-list.component.spec.ts')(format=".")
@ -3702,54 +3854,87 @@ table
:marked
Many custom application directives inject the `Renderer` and call one of its `set...` methods.
很多制定应用程序指令注入`Renderer`并调用它其中一个方法`set...`。
The test environment substitutes the `DebugDomRender` for the runtime `Renderer`.
The `DebugDomRender` updates additional dictionary properties of the `DebugElement`
when something calls a `set...` method.
运行时的`Renderer`在测试环境中的替代品为`DebugDomRender`。
在调用`set...`方法时,`DebugDomRender`更新`DebugElement`额外词典属性。
These dictionary properties are primarily of interest to authors of Angular DOM inspection tools
but they may provide useful insights to testers as well.
这些词典属性主要是为Angular DOM检测工具准备的但是它们可能对测试者提供有用的信息。
table
tr
th Dictionary
th Description
th
:marked
Dictionary
词典
th
:marked
Description
描述
tr
td(style="vertical-align: top") <code>properties</code>
td
:marked
Updated by `Renderer.setElementProperty`.
Many Angular directives call it, including `NgModel`.
被`Renderer.setElementProperty`更新。
很多Angular指令调用它包括`NgModel`。
tr
td(style="vertical-align: top") <code>attributes</code>
td
:marked
Updated by `Renderer.setElementAttribute`.
Angular `[attribute]` bindings call it.
被`Renderer.setElementAttribute`更新。
Angular的`[attribute]`绑定调用它。
tr
td(style="vertical-align: top") <code>classes</code>
td
:marked
Updated by `Renderer.setElementClass`.
Angular `[class]` bindings call it.
被`Renderer.setElementClass`更新。
Angular的`[class]`绑定调用它。
tr
td(style="vertical-align: top") <code>styles</code>
td
:marked
Updated by `Renderer.setElementStyle`.
Angular `[style]` bindings call it.
被`Renderer.setElementStyle`更新。
Angular的 `[style]`绑定调用它。
:marked
Here's an example of `Renderer` tests from the <live-example plnkr="bag-specs">live "Specs Bag" sample</live-example>.
下面是<live-example plnkr="bag-specs">在线"Specs Bag"例子</live-example>中`Renderer`测试的例子
+makeExample('testing/ts/app/bag/bag.spec.ts', 'debug-dom-renderer')(format=".")
a(href="#top").to-top Back to top
a(href="#top").to-top 返回顶部
.l.hr
#faq
.l-main-section
:marked
## FAQ: Frequently Asked Questions
## 常见问题
//
:marked
General
@ -3788,26 +3973,58 @@ a(href="#top").to-top Back to top
:marked
### Why put specs next to the things they test?
### 为何将测试的spec配置文件放置到被测试文件的傍边
We recommend putting unit test spec files in the same folder
as the application source code files that they test because
我们推荐将单元测试的spec配置文件放到与应用程序源代码文件所在的同一个文件夹中因为
- Such tests are easy to find
- 这样的测试很容易被找到
- You see at a glance if a part of our application lacks tests.
- Nearby tests can reveal how a part works in context.
- 你可以一眼看出应用程序的那些部分缺乏测试。
- Nearby tests can reveal how a part works in context.
- 临近的测试可以展示代码是如何在上下文中工作的
- When you move the source (inevitable), you remember to move the test.
- 当你移动代码(无可避免)时,你记得一起移动测试
- When you rename the source file (inevitable), you remember to rename the test file.
- 当你重命名源代码文件(无可避免),你记得重命名测试文件。
.l-hr
#q-specs-in-test-folder
:marked
### When would I put specs in a test folder?
### 什么时候我应该把测试spec文件放到测试目录中
Application integration specs can test the interactions of multiple parts
spread across folders and modules.
They don't really belong to part in particular so they don't have a
natural home next to any one file.
应用程序的整合测试spec文件可以测试横跨多个目录和模块的多个部分之间的互动。
它们不属于任何部分,很自然,没有特别的地方存放它们。
It's often better to create an appropriate folder for them in the `tests` directory.
通常,在`test`目录中为它们创建一个合适的目录比较好。
Of course specs that test the test helpers belong in the `test` folder,
next to their corresponding helper files.
当然,用来测试**测试助手对象**的测试spec文件也属于`test`目录,与它们对应的助手文件相邻。