diff --git a/public/docs/ts/latest/guide/testing.jade b/public/docs/ts/latest/guide/testing.jade
index 1e267e8f63..e2dde19de7 100644
--- a/public/docs/ts/latest/guide/testing.jade
+++ b/public/docs/ts/latest/guide/testing.jade
@@ -38,7 +38,7 @@ block includes
1. [The first karma test](#1st-karma-test)
- 1. [第一个Karma测试](#1st-karma-test)
+ 1. [第一个Karma测试程序](#1st-karma-test)
1. [Introduction to the Angular testing utilities](#atu-intro)
@@ -53,7 +53,7 @@ block includes
1. [A simple component test](#simple-component-test)
- 1. [简单的组件测试](#simple-component-test)
+ 1. [简单的组件测试程序](#simple-component-test)
- [_configureTestingModule_](#configure-testing-module)
@@ -193,7 +193,7 @@ block includes
1. ["Shallow" component tests with *NO\_ERRORS\_SCHEMA*](#shallow-component-test)
- 1. [使用*NO\_ERRORS\_SCHEMA*来“浅化”组件测试](#shallow-component-test)
+ 1. [使用*NO\_ERRORS\_SCHEMA*来“浅化”组件测试程序](#shallow-component-test)
1. [Test an attribute directive](#attribute-directive)
@@ -252,8 +252,8 @@ block includes
本章所有例子代码都在下面的在线例子中,以供参考、实验和下载。
* 例子应用
- * 第一个测试spec
- * 完整的应用测试spec
+ * 第一个测试程序spec
+ * 完整的应用测试程序spec
* 示范spec包
a(href="#top").to-top Back to top
a(href="#top").to-top 回到顶部
@@ -267,7 +267,7 @@ a(href="#top").to-top 回到顶部
You write tests to explore and confirm the behavior of the application.
- 编写测试来探索和确认应用的行为。
+ 编写测试程序来探索和确认应用的行为。
1. They **guard** against changes that break existing code (“regressions”).
@@ -275,14 +275,14 @@ a(href="#top").to-top 回到顶部
1. They **clarify** what the code does both when used as intended and when faced with deviant conditions.
- 1. 不管代码被正确使用还是错误使用,测试起到**澄清**代码的作用。
+ 1. 不管代码被正确使用还是错误使用,测试程序起到**澄清**代码的作用。
1. They **reveal** mistakes in design and implementation.
Tests shine a harsh light on the code from many angles.
When a part of the application seems hard to test, the root cause is often a design flaw,
something to cure now rather than later when it becomes expensive to fix.
- 1. 测试**暴露**设计和实现可能出现的错误。测试从很多角度为代码亮出警报灯。当应用程序很难被测试时,
+ 1. 测试程序**暴露**设计和实现可能出现的错误。测试程序从很多角度为代码亮出警报灯。当应用程序很难被测试时,
其根本原因一般都是设计缺陷,这种缺陷最好立刻被修正,不要等到它变得很难被修复的时候才行动。
This chapter assumes that you know something about testing. Don't worry if you don't.
@@ -305,7 +305,7 @@ a(href="#top").to-top 回到顶部
You can write and run Angular tests with a variety of tools and technologies.
This chapter describes specific choices that are known to work well.
- 你可以用多种工具和技术来编写和运行Angular测试。本章介绍了一些大家已经知道能良好工作的选择。
+ 你可以用多种工具和技术来编写和运行Angular测试程序。本章介绍了一些大家已经知道能良好工作的选择。
table(width="100%")
col(width="20%")
@@ -322,7 +322,7 @@ table(width="100%")
It ships with an HTML test runner that executes tests in the browser.
[Jasmine测试框架](http://jasmine.github.io/2.4/introduction.html)提供了所有编写基本测试的工具。
- 它自带HTML测试运行器,用来在浏览器中执行测试。
+ 它自带HTML测试运行器,用来在浏览器中执行测试程序。
tr(style=top)
td(style="vertical-align: top") Angular测试工具
@@ -346,7 +346,7 @@ table(width="100%")
[karma测试运行器](https://karma-runner.github.io/1.0/index.html)是在开发应用的过程中
编写和运行单元测试的理想工具。
- 它能成为项目开发和连续一体化进程的不可分割的一部分。本章讲述了如何用Karma设置和运行测试。
+ 它能成为项目开发和连续一体化进程的不可分割的一部分。本章讲述了如何用Karma设置和运行测试程序。
tr(style=top)
td(style="vertical-align: top") Protractor
@@ -358,8 +358,8 @@ table(width="100%")
and a second process runs protractor tests that simulate user behavior
and assert that the application responds in the browser as expected.
- 使用`Protractor`来编写和运行_端对端(e2e)_测试。端对端测试**像用户体验应用程序那样**探索它。
- 在端对端测试中,一条进程运行真正的应用,另一条进程运行Protractor测试,模拟用户行为,判断应用在浏览器中的反应是否正确。
+ 使用`Protractor`来编写和运行_端对端(e2e)_测试程序。端对端测试程序**像用户体验应用程序那样**探索它。
+ 在端对端测试中,一条进程运行真正的应用,另一条进程运行Protractor测试程序,模拟用户行为,判断应用在浏览器中的反应是否正确。
.l-hr
#setup
@@ -374,7 +374,7 @@ table(width="100%")
the deep details of setup appear later in the chapter (_forthcoming_).
A bare minimum of discussion plus the downloadable source code must suffice for now.
- 很多人认为编写测试很有趣。很少有人享受搭建测试环境的过程。
+ 很多人认为编写测试程序很有趣。很少有人享受搭建测试环境的过程。
为了尽快开始有趣的部分,我们在本章后面一点再详细讲述搭建测试环境的细节。
在这里,我们先进行最简单的讨论,再加上源代码供大家下载。
@@ -401,7 +401,7 @@ table(width="100%")
In this chapter, the application and its tests are based on the QuickStart repo.
- 在本章中,应用及其测试是基于《快速起步》库的。
+ 在本章中,应用及其测试程序是基于《快速起步》库的。
.alert.is-helpful
:marked
If your application was based on the QuickStart repository,
@@ -496,7 +496,7 @@ table(width="100%")
`devDependencies` section of the `package.json`.
They were installed when you ran `npm install`.
- 例子中的测试是按照能在`Jasmine`和`Karma`中运行的规格编写的。以上两种“快速途径”配置测试环境,都在`package.json`的`devDependencies`中添加了合适的`Jasmine`和`karma`的`npm`包。
+ 例子中的测试程序是按照能在`Jasmine`和`Karma`中运行的规格编写的。以上两种“快速途径”配置测试环境,都在`package.json`的`devDependencies`中添加了合适的`Jasmine`和`karma`的`npm`包。
你运行`npm install`时就会安装它们。
.l-hr
@@ -508,7 +508,7 @@ table(width="100%")
Start with a simple test to make sure the setup works properly.
- 编写简单的测试,来确认以上的配置是否工作正常。
+ 编写简单的测试程序,来确认以上的配置是否工作正常。
Create a new file called `1st.spec.ts` in the application root folder, `app/`
@@ -520,15 +520,15 @@ table(width="100%")
**The filename extension must be `.spec.ts`**,
the convention adhered to by `karma.conf.js` and other tooling.
- 用Jasmine编写的测试都被叫做**specs**。**文件名后缀必须是`.spec.ts`**,这是`karma.conf.js`和其它工具所坚持和遵守的规约。
+ 用Jasmine编写的测试程序都被叫做**specs**。**文件名后缀必须是`.spec.ts`**,这是`karma.conf.js`和其它工具所坚持和遵守的规约。
:marked
**Put spec files somewhere within the `app/` folder.**
The `karma.conf.js` tells karma to look for spec files there,
for reasons explained [below](#spec-file-location).
- **将测试spec放到`app/`文件夹下的任何位置。**
- `karma.conf.js`告诉`Karma`在这个文件夹中寻找测试spec文件,原因在 [这里](#spec-file-location) 有所解释。
+ **将测试程序spec放到`app/`文件夹下的任何位置。**
+ `karma.conf.js`告诉`Karma`在这个文件夹中寻找测试程序spec文件,原因在 [这里](#spec-file-location) 有所解释。
Add the following code to `app/1st.spec.ts`.
@@ -541,7 +541,7 @@ table(width="100%")
Compile and run it in karma from the command line with this command:
- 使用下面的命令从命令行中编译并在`Karma`中运行上面的测试配置文件。
+ 使用下面的命令从命令行中编译并在`Karma`中运行上面的测试程序。
code-example(format="." language="bash").
npm test
@@ -627,11 +627,11 @@ code-example(format="." language="bash").
:marked
## Test debugging
- ## 调试测试
+ ## 调试测试程序
Debug specs in the browser in the same way you debug an application.
- 在浏览器中,像调试应用一样调试测试spec。
+ 在浏览器中,像调试应用一样调试测试程序spec。
- Reveal the karma browser window (hidden earlier).
@@ -639,7 +639,7 @@ code-example(format="." language="bash").
- Click the "DEBUG" button; it opens a new browser tab and re-runs the tests
- - 点击“DEBUG”按钮;它打开一页新浏览器标签并重新开始运行测试
+ - 点击“DEBUG”按钮;它打开一页新浏览器标签并重新开始运行测试程序
- Open the browser's “Developer Tools” (F12 or Ctrl-Shift-I).
@@ -655,7 +655,7 @@ code-example(format="." language="bash").
- Set a breakpoint in the test
- - 在测试中设置断点。
+ - 在测试程序中设置断点。
- Refresh the browser … and it stops at the breakpoint.
@@ -676,17 +676,17 @@ a(href="#top").to-top 回到顶部
Many tests explore how applications classes interact with Angular and the DOM while under Angular's control.
- 许多测试探索应用的类在被`Angular`控制时,是如何与`Angular`和`DOM`互动的。
+ 许多测试程序探索应用的类在被`Angular`控制时,是如何与`Angular`和`DOM`互动的。
Such tests are easy to write with the help of the Angular testing utilities
which include the `TestBed` class and some helper functions.
- Angular测试工具包含了`TestBed`类和一些辅助函数方法,在它们的帮助下,很容易编写上面那样的测试。
+ Angular测试工具包含了`TestBed`类和一些辅助函数方法,在它们的帮助下,很容易编写上面那样的测试程序。
Tests written with these utilities are the main focus of this chapter.
But they are not the only tests you should write.
- 利用**这些工具**编写的测试是本章的主要焦点。但是它们不是你能写的唯一测试类型。
+ 利用**这些工具**编写的测试程序是本章的主要焦点。但是它们不是你能写的唯一测试类型。
### Isolated unit tests
@@ -713,7 +713,7 @@ a(href="#top").to-top 回到顶部
Such tests require the Angular testing utilities.
孤立的测试不会展示类是如何与Angular互动的。也就是说,它们不会展示组件的类是如何与自己的模板或者其它组件互动的。
- 这样的测试需要Angular测试工具。
+ 这样的测试程序需要Angular测试工具。
### Testing with the Angular Testing Utilities
@@ -728,7 +728,7 @@ a(href="#top").to-top 回到顶部
You tell the `TestBed` to create an instance of the _component-under-test_ and probe that instance with tests.
`TestBed`创建Angular测试模块 - `@NgModule`类 - 通过配置它,你为想要测试的类创造模块环境。
- 通过`TestBed`创建被测试的组件的实例,并使用测试来测探这个实例。
+ 通过`TestBed`创建被测试的组件的实例,并使用测试程序来测探这个实例。
Before each spec, the `TestBed` resets itself to a base state.
The base state includes a default testing module configuration consisting of the
@@ -784,7 +784,7 @@ a(href="#top").to-top 回到顶部
:marked
# The sample application and its tests
- # 例子应用和它的测试
+ # 例子应用和它的测试程序
This chapter tests a cut-down version of the _Tour of Heroes_ [tutorial app](../tutorial).
@@ -800,13 +800,13 @@ a(href="#top").to-top 回到顶部
The following live example runs all the tests of this application
inside the browser, using the Jasmine Test Runner instead of karma.
- 下面的在线例子在浏览器中运行该应用的所有测试,使用的是`Jasmine`测试运行器,而非`Karma`。
+ 下面的在线例子在浏览器中运行该应用的所有测试程序,使用的是`Jasmine`测试运行器,而非`Karma`。
It includes the tests discussed in this chapter and additional tests for you to explore.
This live example contains both application and test code.
Give it some time to load and warm up.
- 它包含了本章讨论的测试和其它测试。本在线例子包含了整个应用和测试代码。给它一些时间来加载。
+ 它包含了本章讨论的测试程序和其它测试程序。本在线例子包含了整个应用和测试代码。给它一些时间来加载。
@@ -849,7 +849,7 @@ a(href="#top").to-top 回到顶部
:marked
Here's the setup for the tests followed by observations about the `beforeEach`:
- 下面是测试的配置和`beforeEach`的细节:
+ 下面是测试程序的配置和`beforeEach`的细节:
+makeExample('testing/ts/app/banner.component.spec.ts', 'setup', 'app/banner.component.spec.ts (setup)')(format='.')
:marked
@@ -935,20 +935,20 @@ a(href="#top").to-top 回到顶部
The tests will assert that `el` contains the expected title text.
最后,这个配置指定`DebugElement`中的**`nativeElement`**DOM元素到属性`el`。
- 测试将判断`el`是否包含期待的标题文本。
+ 测试程序将判断`el`是否包含期待的标题文本。
### The tests
- ### 测试
+ ### 测试程序
Jasmine runs the `beforeEach` function before each of these tests
- 再每个测试之前,Jasmin都一次运行`beforeEach`函数:
+ 再每个测试程序之前,Jasmin都一次运行`beforeEach`函数:
+makeExample('testing/ts/app/banner.component.spec.ts', 'tests', 'app/banner.component.spec.ts (tests)')(format='.')
:marked
These tests ask the `DebugElement` for the native HTML element to satisfy their expectations.
- 这些测试向`DebugElement`获取原生HTML元素,来满足自己的期望。
+ 这些测试程序向`DebugElement`获取原生HTML元素,来满足自己的期望。
#detect-changes
:marked
@@ -960,12 +960,12 @@ a(href="#top").to-top 回到顶部
The first test does so immediately, triggering data binding and propagation of the `title` property
to the DOM element.
- 每个测试都通过调用`fixture.detectChanges()`来通知Angular执行变化检测。第一个测试立刻这么做,触发数据绑定和并将`title`属性发送到DOM元素中。
+ 每个测试程序都通过调用`fixture.detectChanges()`来通知Angular执行变化检测。第一个测试程序立刻这么做,触发数据绑定和并将`title`属性发送到DOM元素中。
The second test changes the component's `title` property _and only then_ calls `fixture.detectChanges()`;
the new value appears in the DOM element.
- 第二个测试在更改组件的`title`属性**之后**才调用`fixture.detectChanges()`。新值出现在DOM元素中。
+ 第二个测试程序在更改组件的`title`属性**之后**才调用`fixture.detectChanges()`。新值出现在DOM元素中。
In production, change detection kicks in automatically
when Angular creates a component or the user enters a keystroke or
@@ -977,7 +977,7 @@ a(href="#top").to-top 回到顶部
The fixture does not automatically push the component's `title` property value into the data bound element,
a fact demonstrated in the following test:
- `TestBed.createComponent`**不会**触发变化检测。该工具不会自动将组件的`title`属性值推送到数据绑定的元素,下面的测试展示了这个事实:
+ `TestBed.createComponent`**不会**触发变化检测。该工具不会自动将组件的`title`属性值推送到数据绑定的元素,下面的测试程序展示了这个事实:
+makeExample('testing/ts/app/banner.component.spec.ts', 'test-w-o-detect-changes', 'app/banner.component.spec.ts (no detectChanges)')(format='.')
:marked
@@ -1002,12 +1002,12 @@ a(href="#top").to-top 回到顶部
:marked
Here are three tests that illustrate how _AutoDetect_ works.
- 下面是展示**自动检测**如何工作的三个测试:
+ 下面是展示**自动检测**如何工作的三个测试程序:
+makeExample('testing/ts/app/banner.component.spec.ts', 'auto-detect-tests', 'app/banner.component.spec.ts (AutoDetect Tests)')(format='.')
:marked
The first test shows the benefit of automatic change detection.
- 第一个测试展示了自动检测的好处。
+ 第一个测试程序展示了自动检测的好处。
The second and third test reveal an important limitation.
The Angular testing environment does _not_ know that the test changed the component's `title`.
@@ -1015,11 +1015,11 @@ a(href="#top").to-top 回到顶部
But a direct, synchronous update of the component property is invisible to _AutoDetect_.
The test must call `fixture.detectChanges()` manually to trigger another cycle of change detection.
- 第二和第三个测试显示了一个重要的局限性。
- Angular测试环境**不会**知道测试改变了组件的`title`属性。
+ 第二和第三个测试程序显示了一个重要的局限性。
+ Angular测试环境**不会**知道测试程序改变了组件的`title`属性。
自动检测只对异步行为比如承诺的解析、计时器和DOM时间作出反应。
但是直接修改组件属性值的这种同步更新是不会触发**自动检测**的。
- 测试必须手动调用`fixture.detectChange()`,来触发新一轮的变化检测周期。
+ 测试程序必须手动调用`fixture.detectChange()`,来触发新一轮的变化检测周期。
.alert.is-helpful
:marked
@@ -1074,7 +1074,7 @@ a(href="#top").to-top 回到顶部
and real services can be trouble.
被测试的组件不一定要注入真正的服务。实际上,服务的复制品(stubs, fakes, spies或者mocks)通常会更加合适。
- spec的主要目的是测试组件,而不是服务。真实的服务可能会有问题。
+ spec的主要目的是测试组件,而不是服务。真实的服务可能自身有问题。
Injecting the real `UserService` could be a nightmare.
The real service might try to ask the user for login credentials and
@@ -1083,7 +1083,7 @@ a(href="#top").to-top 回到顶部
It is far easier and safer to create and register a test double in place of the real `UserService`.
注入真实的`UserService`有可能很麻烦。真实的服务可能询问用户登录凭据,也可能试图连接认证服务器。
- 可能很难拦截这些行为。所以在真实的`UserService`的位置创建和注册`UserService`复制品来的更加容易和安全。
+ 可能很难处理这些行为。所以在真实的`UserService`的位置创建和注册`UserService`复制品,会让测试更加容易和安全。
This particular test suite supplies a minimal `UserService` stub that satisfies the needs of the `WelcomeComponent`
and its tests:
@@ -1100,7 +1100,7 @@ a(href="#top").to-top 回到顶部
The tests need access to the (stub) `UserService` injected into the `WelcomeComponent`.
- 测试需要访问被注入到`WelcomeComponent`中的的`UserService`(stub类)。
+ 测试程序需要访问被注入到`WelcomeComponent`中的`UserService`(stub类)。
Angular has a hierarchical injection system.
There can be injectors at multiple levels, from the root injector created by the `TestBed`
@@ -1167,7 +1167,7 @@ a(href="#top").to-top 回到顶部
:marked
### Final setup and tests
- ### 最后的设置和测试
+ ### 最后的设置和测试程序
Here's the complete `beforeEach` using `TestBed.get`:
@@ -1177,13 +1177,13 @@ a(href="#top").to-top 回到顶部
:marked
And here are some tests:
- 下面是一些测试:
+ 下面是一些测试程序:
+makeExample('testing/ts/app/welcome.component.spec.ts', 'tests', 'app/welcome.component.spec.ts')(format='.')
:marked
The first is a sanity test; it confirms that the stubbed `UserService` is called and working.
- 第一个测试是合法测试,它确认这个被模拟的`UserService`是否被调用和工作正常。
+ 第一个测试程序是合法测试程序,它确认这个被模拟的`UserService`是否被调用和工作正常。
.l-sub-section
:marked
@@ -1200,9 +1200,9 @@ a(href="#top").to-top 回到顶部
The second test validates the effect of changing the user name.
The third test checks that the component displays the proper message when there is no logged-in user.
- 接下来的测试确认当服务返回不同的值时组件的逻辑是否工作正常。
- 第二个测试验证变换用户名字的效果。
- 第三个测试检查如果用户没有登录,组件是否显示正确消息。
+ 接下来的测试程序确认当服务返回不同的值时组件的逻辑是否工作正常。
+ 第二个测试程序验证变换用户名字的效果。
+ 第三个测试程序检查如果用户没有登录,组件是否显示正确消息。
a(href="#top").to-top Back to top
a(href="#top").to-top 回到顶部
@@ -1241,7 +1241,7 @@ a(href="#top").to-top 回到顶部
In general, tests should not make calls to remote servers.
They should emulate such calls. The setup in this `app/shared/twain.component.spec.ts` shows one way to do that:
- 一般来讲,测试不应该向远程服务器发请求。
+ 一般来讲,测试程序不应该向远程服务器发请求。
它们应该仿真这样的请求。`app/shared/twain.component.spec.ts`里的配置是其中一种伪造方法:
+makeExample('testing/ts/app/shared/twain.component.spec.ts', 'setup', 'app/shared/twain.component.spec.ts (setup)')(format='.')
@@ -1276,19 +1276,19 @@ a(href="#top").to-top 回到顶部
:marked
Here are the tests with commentary to follow:
- 下面是接下来带有注解的测试:
+ 下面是接下来带有注解的测试程序:
+makeExample('testing/ts/app/shared/twain.component.spec.ts', 'tests', 'app/shared/twain.component.spec.ts (tests)')
:marked
### Synchronous tests
- ### 同步测试
+ ### 同步测试程序
The first two tests are synchronous.
Thanks to the spy, they verify that `getQuote` is called _after_
the first change detection cycle during which Angular calls `ngOnInit`.
- 前两个测试是同步的。
+ 前两个测试程序是同步的。
在Spy的帮助下,它们验证了在Angular调用`ngOnInit`期间发生的第一次变化检测后,`getQuote`被调用了。
Neither test can prove that a value from the service is be displayed.
@@ -1300,7 +1300,7 @@ a(href="#top").to-top 回到顶部
This test must wait at least one full turn of the JavaScript engine before the
value becomes available. The test must become _asynchronous_.
- 这个测试必须等待JavaScript引擎一整个回合,返回值才会有效。该测试必须要变成**异步的**。
+ 这个测试程序必须等待JavaScript引擎一整个回合,返回值才会有效。该测试程序必须要变成**异步的**。
#async
@@ -1311,14 +1311,14 @@ a(href="#top").to-top 回到顶部
Notice the `async` in the third test.
- 注意第三个测试的`async`方法。
+ 注意第三个测试程序的`async`方法。
+makeExample('testing/ts/app/shared/twain.component.spec.ts', 'async-test', 'app/shared/twain.component.spec.ts (async test)')(format='.')
:marked
The `async` function is one of the Angular testing utilities.
It simplifies coding of asynchronous tests by arranging for the tester's code to run in a special _async test zone_.
- `async`函数是**Angular TestBed**的一部分。通过将测试代码放到特殊的**异步测试区域**来运行,`async`函数简化了异步测试的代码。
+ `async`函数是**Angular TestBed**的一部分。通过将测试代码放到特殊的**异步测试区域**来运行,`async`函数简化了异步测试程序的代码。
The `async` function _takes_ a parameterless function and _returns_ a parameterless function
which becomes the argument to the Jasmine `it` call.
@@ -1332,11 +1332,11 @@ a(href="#top").to-top 回到顶部
`async`函数的参数看起来和普通的`it`参数主体一样。
没有任何地方显示异步特征。
- 比如,它不返回承诺,并且没有`done`方法可调用,因为它是标准的Jasmine异步测试。
+ 比如,它不返回承诺,并且没有`done`方法可调用,因为它是标准的Jasmine异步测试程序。
Some functions called within a test (such as `fixture.whenStable`) continue to reveal their asynchronous behavior.
- 在测试(比如`fixture.whenStable`)里面调用函数时,会继续体现它们的异步行为。
+ 在测试程序(比如`fixture.whenStable`)里面调用函数时,会继续体现它们的异步行为。
.l-sub-section
:marked
@@ -1352,12 +1352,12 @@ a(href="#top").to-top 回到顶部
The test must wait for the `getQuote` promise to resolve in the next turn of the JavaScript engine.
- 测试必须等待`getQuote`在JavaScript引擎的下一回合中被解析。
+ 测试程序必须等待`getQuote`在JavaScript引擎的下一回合中被解析。
This test has no direct access to the promise returned by the call to `testService.getQuote`
which is private and inaccessible inside `TwainComponent`.
- 调用`testService.getQuote`返回的承诺是是私有的,不能被`TwainComponent`访问,这个测试也对其无访问权。
+ 调用`testService.getQuote`返回的承诺是是私有的,不能被`TwainComponent`访问,这个测试程序也对其无访问权。
Fortunately, the `getQuote` promise is accessible to the _async test zone_
which intercepts all promises issued within the _async_ method call.
@@ -1373,7 +1373,7 @@ a(href="#top").to-top 回到顶部
which tells Angular to update the DOM with the quote.
The `getQuote` helper method extracts the display element text and the expectation confirms that the text matches the test quote.
- 然后测试继续运行,并开始另一轮的变化检测(`fixture.detectChanges`),通知Angular使用名言来更新DOM。
+ 然后测试程序继续运行,并开始另一轮的变化检测(`fixture.detectChanges`),通知Angular使用名言来更新DOM。
`getQuote`辅助方法提取出显示元素文本,然后expect语句确认这个文本与预备的名言相符。
#fakeAsync
@@ -1385,7 +1385,7 @@ a(href="#top").to-top 回到顶部
The fourth test verifies the same component behavior in a different way.
- 第四个测试用不同的方法验证同样的组件行为。
+ 第四个测试程序用不同的方法验证同样的组件行为。
+makeExample('testing/ts/app/shared/twain.component.spec.ts', 'fake-async-test', 'app/shared/twain.component.spec.ts (fakeAsync test)')(format='.')
:marked
@@ -1402,13 +1402,13 @@ a(href="#top").to-top 回到顶部
The `fakeAsync` function enables a linear coding style by running the test body in a special _fakeAsync test zone_.
- `fakeAsync`函数通过在特殊的**fakeAsync测试区域**运行测试,让测试代码更加简单直观。
+ `fakeAsync`函数通过在特殊的**fakeAsync测试区域**运行测试程序,让测试代码更加简单直观。
The principle advantage of `fakeAsync` over `async` is that the test appears to be synchronous.
There is no `then(...)` to disrupt the visible flow of control.
The promise-returning `fixture.whenStable` is gone, replaced by `tick()`.
- 对于`async`来说,`fakeAsync`最重要的好处时测试看起来像同步的。里面没有任何承诺。
+ 对于`async`来说,`fakeAsync`最重要的好处是测试程序看起来像同步的。里面没有任何承诺。
没有`then(...)`链来打断控制流。
.l-sub-section
@@ -1445,7 +1445,7 @@ a(href="#top").to-top 回到顶部
To more fully appreciate the improvement, imagine a succession of asynchronous operations,
chained in a long sequence of promise callbacks.
- 虽然这个例子非常简单,但是它已经比第三个测试更易阅读。
+ 虽然这个例子非常简单,但是它已经比第三个测试程序更易阅读。
为了更充分的体会`fakeAsync`的好处,试想一下一连串的异步操作,被一长串的承诺回调链在一起。
#jasmine-done
@@ -1468,7 +1468,7 @@ a(href="#top").to-top 回到顶部
Here is a `done` version of the previous two tests:
- 下面是上面两个测试的`done`版本:
+ 下面是上面两个测试程序的`done`版本:
+makeExample('testing/ts/app/shared/twain.component.spec.ts', 'done-test', 'app/shared/twain.component.spec.ts (done test)')(format='.')
:marked
Although we have no direct access to the `getQuote` promise inside `TwainComponent`,
@@ -1503,7 +1503,7 @@ a(href="#top").to-top 回到顶部
Everything necessary to compile them was in memory at test runtime.
到目前为止还是这样的。
- 每个被测试的组件的`@Component`元数据都有`template`属性,制定**内联模板**。
+ 每个被测试程序的组件的`@Component`元数据都有`template`属性,制定**内联模板**。
没有组件有`styleUrls`属性。所有编译它们所需要的资源,在测试时都已经在内存里。
The `DashboardHeroComponent` is different.
@@ -1528,7 +1528,7 @@ a(href="#top").to-top 回到顶部
WebPack developers need not call `compileComponents` because it inlines templates and css
as part of the automated build process that precedes running the test.
- WebPack开发者不需要调用`compileComponents`,因为在运行测试时,内联模板和CSS文件是自动编译流程的一部分。
+ WebPack开发者不需要调用`compileComponents`,因为在运行测试程序时,内联模板和CSS文件是自动编译流程的一部分。
:marked
The `app/dashboard/dashboard-hero.component.spec.ts` demonstrates the pre-compilation process:
@@ -1565,7 +1565,7 @@ a(href="#top").to-top 回到顶部
Some or all of these components could have external templates and css files.
`TestBed.compileComponents` compiles them all asynchronously at one time.
- 本章后面的测试有更多声明组件,它们中间的一些导入应用模块,这些模块有更多的声明组件。
+ 本章后面的测试程序有更多声明组件,它们中间的一些导入应用模块,这些模块有更多的声明组件。
一部分或者全部组件可能有外部模板和CSS文件。
`TestBed.compileComponents`一次性异步编译所有组件。
@@ -1598,7 +1598,7 @@ a(href="#top").to-top 回到顶部
_synchronous_ `beforeEach` that completes the setup steps and runs tests ... as described in the next section.
`DashboardHeroComponent`spec中,异步的`beforeEach`下面紧接着**同步**的`beforeEach`,
- 用来完成设置步骤和运行测试...下面小节做了详细的解释。
+ 用来完成设置步骤和运行测试程序...下面小节做了详细的解释。
.l-hr
@@ -1619,7 +1619,7 @@ a(href="#top").to-top 回到顶部
The tests should set input values and listen for output events.
测试的目的是验证这样的绑定和期待的那样正常工作。
- 测试应该设置导入值并监听导出事件。
+ 测试程序应该设置导入值并监听导出事件。
The `DashboardHeroComponent` is tiny example of a component in this role.
It displays an individual hero provided by the `DashboardComponent`.
@@ -1649,7 +1649,7 @@ a(href="#top").to-top 回到顶部
While testing a component this simple has little intrinsic value, it's worth knowing how.
Three approaches come to mind:
- 虽然测试这么简单的组件没有什么内在价值,但是它的测试是值得学习的。
+ 虽然测试这么简单的组件没有什么内在价值,但是它的测试程序是值得学习的。
有三种候选测试方案:
1. Test it as used by `DashboardComponent`
@@ -1714,7 +1714,7 @@ a(href="#top").to-top 回到顶部
The first test follows:
- 紧接着第一个测试:
+ 紧接着第一个测试程序:
+makeExample('testing/ts/app/dashboard/dashboard-hero.component.spec.ts', 'name-test', 'app/dashboard/dashboard-hero.component.spec.ts (name test)')(format='.')
:marked
@@ -1723,7 +1723,7 @@ a(href="#top").to-top 回到顶部
test must match the element value with the uppercased name:
它验证了英雄名字通过绑定被传递到模板了。这里有个额外步骤。模板将英雄名字传给Angular的`UpperCasePipe`,
- 所以测试必须使用大写名字来匹配元素的值:
+ 所以测试程序必须使用大写名字来匹配元素的值:
+makeExample('testing/ts/app/dashboard/dashboard-hero.component.html')(format='.')
:marked
.alert.is-helpful
@@ -1739,25 +1739,25 @@ a(href="#top").to-top 回到顶部
The second test verifies click behavior. Clicking the hero should raise a `selected` event that the
host component (`DashboardComponent` presumably) can hear:
- 第二个测试验证点击行为。点击英雄应该出发`selected`事件,可供宿主组件(`DashbaordComponent`)监听:
+ 第二个测试程序验证点击行为。点击英雄应该出发`selected`事件,可供宿主组件(`DashbaordComponent`)监听:
+makeExample('testing/ts/app/dashboard/dashboard-hero.component.spec.ts', 'click-test', 'app/dashboard/dashboard-hero.component.spec.ts (click test)')(format='.')
:marked
The component exposes an `EventEmitter` property. The test subscribes to it just as the host component would do.
- 这个组件公开`EventEmitter`属性。测试像宿主组件那样来描述它。
+ 这个组件公开`EventEmitter`属性。测试程序像宿主组件那样来描述它。
The `heroEl` is a `DebugElement` that represents the hero `
`.
The test calls `triggerEventHandler` with the "click" event name.
The "click" event binding responds by calling `DashboardHeroComponent.click()`.
`heroEl`是个`DebugElement`,它代表了英雄所在的`