阅读Angular测试指南时，写测试代码的过程中的笔记

2 年 ago

雅, 悟

1 minute

在阅读《Testing – ts – GUIDE》的过程中，我会总结我所查询和遇到的问题以及遇到的困难，这是正在写作中的部分。

创建一个样例项目并保存好。

前提 – Qian ti

（SPAではなく、Rails側からhtml返してから一部をAngular管理化にする感じのアプリケーションです）

ソースはTypeScript
ビルド周りはWebpack
テストランナーにはKarma
テストライブラリはJasmine

对于 Pipe 和 Service，应独立进行单元测试，而对于 Component，则应使用 Angular 测试工具库。

你应该为管道和服务编写独立的单元测试。

你也可以对组件进行独立测试。然而，独立的单元测试无法揭示组件与Angular的交互方式。特别是，它们无法揭示组件类如何与自己的模板或其他组件交互。

在这里写着。 Angular测试工具基本上是用于组件的测试工具，我认为对于管道和服务进行测试，不需要使用Angular特定的工具，只需使用Jasmine测试框架的话，就用Jasmine；如果使用的是Mocha测试框架，就用Mocha即可。

将测试文件放置在源代码所在的目录中。

尽管不是基于angular-cli的项目，但我生成了一个使用angular-cli的随意项目作为参考。

查看生成的项目，会发现测试文件也包含在src/app文件夹下的位置。

src/app/
├── app.component.css
├── app.component.html
├── app.component.spec.ts
├── app.component.ts
└── app.module.ts

这个目录结构是Angular的方针，同时在文档中也有相应说明。

https://angular.io/docs/ts/latest/guide/testing.html#!#q-spec-file-location

将单元测试规范文件放在与它们所测试的应用源代码文件相同的文件夹中是一个好主意：

这样的测试很容易找到。
一眼就能看出你的应用程序部分是否缺少测试。
附近的测试能揭示部分如何在上下文中工作。
当你移动源代码（不可避免）时，你会记得移动测试文件。
当你重命名源文件（不可避免）时，你会记得重命名测试文件。

请使用中文将以下内容意译成一种译文即可：
（Paraphrase↓）

ソースをリネームしたらテストも移動するのを忘れづらい

就我个人而言，我觉得测试文件的存放位置可以在源代码和不同目录中，或者在同一目录中都可以。事实上，在服务器端的Rails中，源代码和测试是放在不同目录下的（但是通过命名规范能够看出它们之间的关系）。

只需用一种选项用中文重新表述以下内容：
我决定按照Angular指南遵循这个框架所推荐的方式，只是带有一种这样的感觉。

组件的测试（准备）

进行组件的测试需要执行以下两个步骤。

テストダブル（サービスの代わり）をコンポーネントに提供する

将模板嵌入到组件的内联位置。

尽管不在Angular测试指南范围内，我仍然安装了一个名为angular2-template-loader的加载器，并将其配置到用于测试的webpack配置文件中。

angular2-template-loader是做什么的呢？它会使用正则表达式捕获templateUrl，并将其转换为template: require(‘hogehoge.html’)的格式。结果就是将模板文件直接指定给组件元数据的template属性。

这样一来，Angular测试指南中所写的compileComponents()就不再需要了。指南上也明确写着“对于webpack屋来说是不必要的”。

webpack开发人员无需调用compileComponents，因为它会将模板和CSS内联到自动构建过程中，该过程在运行测试之前进行。

看到 “angular2-template-loader” 的存储库时，作者似乎略显不积极，这有点让人遗憾，但如果真的有需要，我认为可以写一个相同的加载器来完成相同的任务（因为正则表达式可能不太准确，取决于 templateUrl 的写法可能无法匹配）。

提供将“测试替身（代替服务）”作为组件的选项。

在配置组件时，使用 TestBed.configureTestingModule 方法时，我们会配置测试替身而不是实际的服务。


TestBed.configureTestingModule({
  providers: [
      // 本物のServiceではなく, テストダブル（スタブ）をコンポーネントに提供する
      { provide: MyService, useValue: myServiceStub },
  ]
});

我通过阅读”了解Angular2的DI-在Qiita上”这篇文章，理解了这是关于”提供myServiceStub作为MyService给组件使用”的意思。

组件的测试（主体）

测试组件的流程可能如下所示。

TestBed.configureModule() でコンポーネントの設定をする

TestBed.createComponent() でコンポーネントを生成する
コンポーネントをお好みの状態にする

（例：「ブログ記事が0件の状態のテストをしたい」　=> componentInstance.posts = [];）

detectChanges() で変更検知をする
debugElement から要素をとってきて表示のテストをしたりする

暂时来说，我们现在可以测试Angular组件了。

使用虚拟数据

由于不能使用真实的API响应，因此在测试执行时需要使用替代API返回值的虚拟数据。在组件测试中，可能只需要测试调用Service的方法和在调用后属性是否处于期望的状态，但要对调用API的Service本身进行测试，就需要虚拟数据。

因此，我创建了一个类似于test/fixtures/user.json的文件，并对其进行了读取操作。

我参考了以下链接，在karma.conf.js中的files中添加了虚拟数据的路径，并增加了included: false的指定修改。

Karma + Jasmine でフィクスチャを使う – Qiita

请参考

Angular2のDIを知る – Qiita