在生产环境中,常常会在父子组件的链接上出现一些BUG。总结来说,这些BUG大体分为两类。第一类父组件向子组传值的错误,第二类是子组件向父组件弹值的错误。除上述错误,有些时候还会出现方法、属性绑定失败的错误,但这往往是由于拼写造成的(聪明的IDE以及各种工具会替我们快速的完成这一切)。 ### 父组件传值 在父子组件在互相传值的过程中,父组件向子组件传入了字段不全或类型不对的数据。比如子组件有以下输入: ```typescript @Input() input(a: any) : void { console.log(a.b.c.d); } ``` 此时如果父组件如果如下调用子组件: ```html <app-子组件 [a]="{b: {}}"></app-子组件> ``` 此时由于传入的`a`并在子组件中调用`a.b.c.d`时,会产生一个在非object上调用`d`的异常。 ### 子组件弹值 子组件向上弹值产生的错误也大多发生在数据校验的层面上。比如子组件向父组件弹值为`{b: {}}`,但在父组件中却调用了`xx.b.c.d`,则仍然会发生一个在非object上调用`d`的异常。 ## 子组件测试 子组件测试更准备的描述应该为:嵌套组件测试。Angular官方文档推荐使用组件提供桩(Stub)的方式来模拟到嵌套组件。但在实际生产过程中,我们发现这种提供桩的方法并不能够适应子组件的变更情况,这使单元测试失去了其“保障”的作用。在使用组件提供桩的测试方案中,当子组件有功能变更时,单元测试测试通过,却在集成测试或生产环境中发生了错误。 > [info] 尽信书不如无书,看教程也是一样,不要完全地相信我们。此处的思想与Angular给出的测试思想相冲突,希望日后我们能够找到更好的贴近于Angular的官方测试方案。在学习过程中:永远不要怀疑一个人,永远不要放弃怀疑一个人。 有的同学可能对使用单元测试来完成父子组件交互测试的方式有怀疑。他认为在开发过程中,已经手动的完成了父子组件的交互测试,且观察了交互的结果,所以这种使用代码的方式来进行父子组件嵌套测试实际上是冗余的。 其实不然,我们单元测试的目的在于保障在日后的迭代开发中,自己开发的功能不被其它的成员或是自己误杀掉。也是就是说:单元测试的目的并不在于保障目前组件的功能正常,而在于保障日后该组件的功能一直正常。在实际的开发中,每个组件必然不是独立的,一个项目开发完成后随即进行维护期,如果项目动作的好,还会进行功能的修正与更新。单元测试的作用正是:保障在日后对其它关联模块进行修正更新时,当前组件的功能保持正常。 既然错误往往是输入或输出引发的,那么我们在父子组件的嵌套测试中,重点也应该放在输入与输出上。同时,由于使用组件提供桩的方案不能够适应子组件的变化,所以在测试过程中不应该使用组件测试桩,而是应该使用真实的组件。 我们在测试文件中新建一个用于父子组件交互的方法: ```typescript +++ b/first-app/src/app/student/student.component.spec.ts @@ -44,4 +44,10 @@ describe('StudentComponent', () => { // 在后台模拟数据返回以后,然后启动变更检测来更新V层,断言table列表中的`tr`大于一行。 expect(table.querySelectorAll('tr').length).toBeGreaterThan(1); }); + + fit('与分页子组件交互测试', () => { + // 模拟后台立即返回数据,接着使用返回的数据重新渲染组件 + getTestScheduler().flush(); + fixture.detectChanges(); + }); }); ``` 然后使用`ng t`来启动单元测试。 ### 获取子组件 5.6小节我们已经掌握了在父组件中获取子组件的方法:使用测试夹具中`debugElement`对上的`query()`方法。 ```typescript +++ b/first-app/src/app/student/student.component.spec.ts @@ -6,6 +6,7 @@ import {getTestScheduler} from 'jasmine-marbles'; import {MockApiTestingModule} from '../mock-api/mock-api-testing.module'; import {By} from '@angular/platform-browser'; import {PageModule} from '../clazz/page/page.module'; +import {PageComponent} from '../clazz/page/page.component'; describe('StudentComponent', () => { let component: StudentComponent; @@ -49,5 +50,9 @@ describe('StudentComponent', () => { // 模拟后台立即返回数据,接着使用返回的数据重新渲染组件 getTestScheduler().flush(); fixture.detectChanges(); + + // 获取分页组件 + const pageComponent = fixture.debugElement.query(By.directive(PageComponent)).componentInstance as PageComponent + expect(pageComponent).toBeTruthy(); }); }); ``` 单元测试通过,说明成功的获取到了子组件`pageComponent`。 ![image-20210525085408730](https://img.kancloud.cn/35/a9/35a99431918bdc0cca59f642171d2e68_1034x194.png) 获取子组件的目的不仅仅在于支持后续子组件的输入、输出测试。子组件获取成功,同时也证明了子组件在初始化过程中没有发生异常。如果后续对`input()`的测试成功,则足以说明:父组件在初始化时绑定了子组件的输入`input()`,而且在调用的过程中没有发生异常。 接下来使用代码来保障当前组件与分页子组件间的交互是正常且符合预期的。 ### Input()测试 当前组件在V层中如下调用了分页组件: ```html <app-page [page]="pageData" (bePageChange)="onPage($event)"></app-page> ``` 输入项为`page`并将其赋值为`pageData`,为了保障该功能日后不被误杀,我们需要确保当前组件的`pageData`成功的绑定到了子组件中的`page()`方法。在单元测试中,可以将被测试调用的方法`mock`掉,然后断言这个方法被调用: ```typescript expect(pageComponent).toBeTruthy(); + + // input测试,先mock掉子组件被调用的方法 + spyOn(pageComponent, 'page'); }); }); ``` 跟着上面的代码来做的话,IDE会报一个异常:在`pageComponent`上找不到`page`方法。这是由于`PageComponent`上的`page()`方法以`set`关键字来声明,该声明方式代表`page()`被看做一个字段来处理,当i使用`pageComponent.page = 1`时,则会自动调用`set page()`方法。 由于`set page()`并没有被看做一个方法来对象,所以`spyOn()`方式并不适用。在`Jasmine`中应该使用`spyOnProperty(object, propertyName, accessType)`在类似`set page()`的方法中安插间谍。 ```typescript // input测试,先mock掉子组件被调用的方法 - spyOn(pageComponent, 'page'); + const spy = spyOnProperty(pageComponent, 'page', 'set'); }); }); ``` 最后继续添加注释: ```typescript // input测试,先mock掉子组件被调用的方法 const spy = spyOnProperty(pageComponent, 'page', 'set'); // 然后重新为当前组件的pageData赋值 // 重新渲染子组件,触发set page()方法 // 断言子组件对应的方法被成功调用 }); ``` 完成功能: ```typescript // input测试,先mock掉子组件被调用的方法 const spy = spyOnProperty(pageComponent, 'page', 'set'); // 然后重新为当前组件的pageData赋值 const pageData = {...{}, ...component.pageData}; ① component.pageData = pageData; // 重新渲染子组件,触发set page()方法 fixture.detectChanges(); // 断言子组件对应的方法被成功调用 expect(spy).toHaveBeenCalledWith(pageData); ② }); ``` - ① `{...{}, ...data}`可以快速完成`data`对象的`clone`从而得到一个与`data`一致的新对象。 - ② `spy`此时代表的便是分页组件上被安插了间谍的`set page()`方法。 需要注意的是,上述代码在初始化一个`pageData`时,采用的是对象`clone`的方法,这种方法是非常有必要的,它保障了数据的一致性。 ### output()输出测试 与输入的测试大同小异,输出测试即子组件向父组件的弹值测试。与父组件在渲染过程中向子组件主动传值不同,子组件向父组件的传值一般是被动的。我们可以通过是否成功获取子组件来判断父组件向子组件传值时是否发生异常,但却不可以以此来判断子组件向父组件传值是否发生异常。 所以子组件输出测试,应该首先模拟一下子组件的输出,然后重新渲染组件,从而查看子组件的数据弹出是否会引发父组件异常。 ```typescript // 断言子组件对应的方法被成功调用 expect(spy).toHaveBeenCalledWith(pageData); // 触发子组件弹出并重新进行渲染,未发生异常说明子组件弹值后父组件可以正确处理子组件的弹出数据 }); ``` 真实的数据被弹出父组件未发生异常后,便可以继续进行output方法的调用测试了: ```typescript // 断言子组件对应的方法被成功调用 expect(spy).toHaveBeenCalledWith(pageData); // 触发子组件弹出并重新进行渲染,未发生异常说明子组件弹值后父组件可以正确处理子组件的弹出数据 // output测试,先mock掉父组件的方法 // 调用子组件的弹射器,向父组件传值 // 断言父组件的方法被调用 }); ``` 思想有了,补充代码便是一件像聊天一样的事情: 一、触发子组件弹出 ```typescript // 触发子组件弹出并重新进行渲染,未发生异常说明子组件弹值后父组件可以正确处理子组件的弹出数据 pageComponent.bePageChange.emit(2); fixture.detectChanges(); // output测试,先mock掉父组件的方法 // 调用子组件的弹射器,向父组件传值 // 断言父组件的方法被调用 ``` 为了防止子组件的数据弹出可能会触发mockApi的数据请求,我们还会习惯性的在组件渲染前加入立即返回模拟数据代码: ```typescript // 触发子组件弹出并重新进行渲染,未发生异常说明子组件弹值后父组件可以正确处理子组件的弹出数据 pageComponent.bePageChange.emit(2); getTestScheduler().flush(); fixture.detectChanges(); // output测试,先mock掉父组件的方法 // 调用子组件的弹射器,向父组件传值 // 断言父组件的方法被调用 ``` 二、测试弹出数据成功被组件接收 ```typescript // output测试,先mock掉父组件的方法 const onPageSpy = spyOn(component, 'onPage'); // 调用子组件的弹射器,向父组件传值 pageComponent.bePageChange.emit(1); // 断言父组件的方法被调用 expect(onPageSpy).toHaveBeenCalledWith(1); }); ``` 测试通过: ![image-20210525085408730](https://img.kancloud.cn/35/a9/35a99431918bdc0cca59f642171d2e68_1034x194.png) ## 总结 在进行嵌套组件测试时,主要测试以下几点: 1. 父组件向子组件传值时,子组件不发生异常。 2. 父组件成功地向子组件传了值。 3. 子组件成功地向父组件传了值。 4. 子组件向父组件传值时,父组件不发生异常。 上述几点我们在单元测试中分别使用以下方法来进行保障: 1. 模拟API返回数据,渲染组件,成功获取子组件说明子组件成功渲染,父组件向子组件传值未发生异常。 2. mock掉子组件的`@Input()`属性,变更父组件绑定到子组件的变量,重新渲染组件,断方间谍方法并调用。 3. 触发子组件的数据弹射,重新渲染组件,未发生异常说明父组件接收子组件弹射的数据后未发生异常。 4. mock掉父组件对应的方法,触发数据弹出,断言父组件对应方法被调用。 如此以来,当前组件与子分页组件的交互便开始有单元测试这个"护身符"来"保佑"了。日后一旦某些功能被误杀掉,单元测试便会及时跳出来告知开发者:当前代码已经将我的某些功能误杀了。从而避免了一些迭代开发过程中引发的关联性错误。 最后移除项目中的`fit`进行整体项目测试,未发生异常说明我们当前开发并未对历史上的其它组件功能产生影响。 | 链接 | 名称 | | ------------------------------------------------------------ | -------------------- | | [https://jasmine.github.io/tutorials/spying_on_properties](https://jasmine.github.io/tutorials/spying_on_properties) | Spying on properties | | [https://github.com/mengyunzhi/angular11-guild/archive/step7.4.4.zip](https://github.com/mengyunzhi/angular11-guild/archive/step7.4.4.zip) | 本节源码 |