本篇文章和大家聊聊Angular中的單元測試，通過示例介紹一下單元測試工具（Karma + Jasmine）的使用方法。

做了多年的Angular的前端開發(fā)，一直沒有膽量對前端進行單元測試，原因一是前端是跟用戶打交道，不好測試，原因二是項目的時間壓力沒有精力弄單元測試。這也就導(dǎo)致在前端開發(fā)時，業(yè)務(wù)一旦改變，就要人肉進行測試。費時又沒有技術(shù)含量，直接讓我懷疑人生。

最近得空，索性就把Angular的單元測試研究了一把。Angular其實自己有單元測試的工具：Karma + Jasmine：

• Karma：Karma是為測試JavaScript代碼而生的自動化測試管理工具，可監(jiān)控文件的變化，自動執(zhí)行測試。
• Jasmine：用來編寫Javascript測試的的框架。

【相關(guān)教程推薦：《angular教程》】

第一個測試用例

當(dāng)創(chuàng)建Angular應(yīng)用后，在package.json文件中已經(jīng)添加了Karma和Jasmine的依賴性：

"karma": "~1.7.1",   "karma-chrome-launcher": "~2.2.0", "karma-coverage-istanbul-reporter": "~2.0.0", "karma-jasmine": "~1.1.1", "karma-jasmine-html-reporter": "^0.2.2",

做過后端測試的同行，估計已經(jīng)知道這些組件的分工了：

• karma：Karma核心組件
• karma-chrome-launcher：Chrome發(fā)射器，測試會在Chrome上執(zhí)行
• karma-coverage-istanbul-reporter：coverage報告
• karma-jasmine：Jasmine核心組件
• karma-jasmine-html-reporter：Html測試報告

在src目錄下會看到名為：karma.conf.js、test.ts的兩個文件。

karma.conf.js：Karma的配置文件，其中需要重點關(guān)注的配置有：

• frameworks：使用的測試框架，這里使用Jasmine

• port：測試使用的端口

• autoWatch：是否自動監(jiān)測測試代碼的改變，自動執(zhí)行測試

• plugins：測試使用到的插件，與package.json文件保持一致

• browsers：測試運行使用的瀏覽器，這里使用Chrome，如果你需要使用其他瀏覽器，需要通過npm安裝瀏覽器發(fā)射器，并在plugins和這里設(shè)置，例如使用Safari：

  npm install karma-safari-launcher --save-dev  plugins: [     require('karma-safari-launcher') ] browsers: ['Safari'],

test.ts：測試入口文件，其中初始化了測試環(huán)境以及指定所有測試文件

在app目錄下，還會找到一個名為app.component.spec.ts的文件，這就是一個Jasmine的測試，內(nèi)容如下：

import { TestBed, async } from '@angular/core/testing'; import { AppComponent } from './app.component'; //測試入口，參數(shù)為測試名、方法 describe('AppComponent', () => {   //每個測試用的Setup   beforeEach(async(() => {     TestBed.configureTestingModule({       declarations: [         AppComponent         ],     }).compileComponents();   }));    //測試用例   it('should create the app', async(() => {     const fixture = TestBed.createComponent(AppComponent);     const app = fixture.debugElement.componentInstance;     expect(app).toBeTruthy();   }));    it(`should have as title 'test-demo'`, async(() => {     const fixture = TestBed.createComponent(AppComponent);     const app = fixture.debugElement.componentInstance;     //斷言，期望值是否滿足要求     expect(app.title).toEqual('test-demo');   }));    it('should render title in a h1 tag', async(() => {     const fixture = TestBed.createComponent(AppComponent);     fixture.detectChanges();     const compiled = fixture.debugElement.nativeElement;     //通過querySelector獲取頁面元素     expect(compiled.querySelector('h1').textContent).toContain('Welcome to test-demo!');   }));    //每個測試用例的TearDown   afterEach(function() {     //清除測試數(shù)據(jù)   }); });

上述代碼使用了Jasmine的語法，關(guān)于Jasmine的更詳細(xì)介紹，參見JavaScript 單元測試框架：Jasmine 初探。這里不贅述。

執(zhí)行: ng test，就會看到上述文件的測試報告：

另外在測試報告中還可單擊某個測試單獨執(zhí)行，報告如下：

填坑

對于Pipe、Service、Router等組件的測試，可參見Angular文檔，這里重點講述下在測試中遇到的各種坑。

No provider ***

測試時，如果被測組件需要其他第三方組件、servcie或pipe，沒有被引入，就會出現(xiàn)No provider 的錯誤，解決方法很簡單，在beforeEach中使用imports或provider引入即可：

beforeEach(async(() => {     TestBed.configureTestingModule({       declarations: [         //這里聲明       ],       imports: [         //這里引入       ],       providers: [         //這里引入       ],       schemas: [CUSTOM_ELEMENTS_SCHEMA],     })       .compileComponents();   }));

請求超時

在開發(fā)時，異步請求由于網(wǎng)絡(luò)原因常會出現(xiàn)TimeOut的錯誤，通常的解決方法是設(shè)置TimeOut時間的上限，并對TimeOut錯誤作出人性化的提示。在測試時也同樣會發(fā)生TimeOut的錯誤：

解決辦法是可以在某個測試用例中設(shè)置TimeOut的時間：

it('#loadBalance for BCT should return real value', async () => {   jasmine.DEFAULT_TIMEOUT_INTERVAL = 1000000;   ... })

或者在BeforeEach中統(tǒng)一設(shè)置TimeOut時間：

describe("my async specs", function() {     var originalTimeout;     beforeEach(function() {       originalTimeout = jasmine.DEFAULT_TIMEOUT_INTERVAL;       jasmine.DEFAULT_TIMEOUT_INTERVAL = 1000000;     });      ...      afterEach(function() {       jasmine.DEFAULT_TIMEOUT_INTERVAL = originalTimeout;     });   });

定義測試Environment

Angular缺省針對開發(fā)和產(chǎn)品提供了不同的Environment，對于測試，我們同樣可以設(shè)置Enviroment。

在src/environment下創(chuàng)建environment.test.ts，并修改angular.json內(nèi)容：

"architect":{     "test":{         ...         "configurations": {             "test": {               "fileReplacements": [                 {                   "replace": "src/environments/environment.ts",                   "with": "src/environments/environment.test.ts"                 }               ]             }           }     } }

修改package.json文件：

"scripts": {   "test": "ng test --configuration=test", }

這樣執(zhí)行如下命令：

npm test //或者 ng test --configuration=test

執(zhí)行測試時，使用的就是environment.test.ts文件中配置的內(nèi)容。

測試數(shù)據(jù)回滾

做過Grails開發(fā)的伙計應(yīng)該知道，單元測試、集成測試后，數(shù)據(jù)庫中的測試數(shù)據(jù)會通過配置文件清除掉。在前端測試中，測試數(shù)據(jù)需要自行調(diào)用清除代碼，對于使用LocalStorage、SessionStorage保持的數(shù)據(jù)亦是如此，方法很簡單，在afterEach添加清除代碼：

describe("my async specs", function() {      afterEach(function() {     //在這里清除測試數(shù)據(jù)   }); });

與StoryBook的配合

先前我發(fā)布了一篇題為《StoryBook實戰(zhàn)》的文章，StoryBook也是用來測試組件的，它與Karma+Jasmine有什么區(qū)別呢？

二者都能測試的：

• Pipe

• Servcie

• Component

StoryBook不能測、Karma + Jasmine可測試的：

• Router

• Component的界面元素屬性、Input、Output

Karma + Jasmine不能做的，StoryBook能做的：

• Component交互測試

• 組件管理

• 編寫組件文檔

從上面可以看出，Storybook進行的是黑盒測試，Karma + Jasmine則注重白盒測試，二者側(cè)重點不同，沒有誰強誰弱之分，只有揚長避短，利用好各自的優(yōu)點，方可讓前端測試更完美，將前端bug扼殺在開發(fā)階段。

一些前端測試感悟

雖然前端開發(fā)的工作比較繁瑣，也是客戶Challenge最多的地方，但是不代表前端只有頁面，沒有架構(gòu)。以前之所以覺得Angular的單元測試難做，就是覺得都是頁面的東西怎么測？其實，終其原因，還是沒有架構(gòu)，所有的代碼都集中在Component中，為了趕進度，通過拷貝、粘貼，怎么快怎么來。結(jié)果，悲劇了，后期代碼維護困難，一點改動就需要人肉測試。

費時不說，開發(fā)人員也沒有成長。接觸Angular前端測試后，我的腦海里又出現(xiàn)了“測試驅(qū)動開發(fā)”。一段好代碼，前提是要易于測試，不管這段代碼是用于前端還是后端。 前端開發(fā)人員不僅僅要關(guān)注頁面的易用性、美觀性，同樣需要關(guān)注前端的架構(gòu)，一個易于測試的架構(gòu)才是最好的“武器”。