最新现在开始为你的Angular应用编写测试（上）_创建一个spike(1)，2024年最新2024届毕业生还没找到软件测试开发工作

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

（2）测试有利于重构。有单元测试的代码在功能扩展和重构时，操作成本更低；

（3）测试能提升代码质量。一旦开始写测试，你就会发现自己的代码组织结构多么混乱，会逼着自己从代码的源头设计来解决问题，写出可测试的代码，降低代码圈复杂度。

鉴于此，我下定决心要给自己的项目写单元测试，并且已经隐约有了眉目，应该如何去写。

人人都难以开始动手的原因

上面扯了那么一大堆，其实大家都明白。“道理我都懂，就是觉得很难以下手”。所以在开始之前，我们必须要先回答两个问题，也是大多数人迟迟不愿意开始书写测试的原因：

写测试会该开发者带来极大的成本

要达到或者接近100% 的单元测试覆盖率，代码量基本上要翻倍。比如说，知名的验收测试工具FitNesse 拥有6.4 万行代码，其中2.8 万行代码是单元测试代码（数据来自《程序员的职业素养》）。

这是一个让人望而生畏的比例，我也曾一度对“写测试会给开发者带来极大的成本”这个观点深以为然，直到我看到这样一句话，在此拿出来跟大家分享：

有人会告诉你TDD 能减少缺陷，但是有成本，你会编写比产品代码多两倍的测试代码，所以会降低速度。这种假设认为影响软件开发的因素是打字速度，但这不是真的，实际上的影响因素是阅读需求文档、编写文档、开会、定位和修复bug。

这句话就不进行解读了，大家细品。

前端在测试领域遇到的种种困难

也就是我们在引子里提到的那些问题，既然从上述角度来看，非常难以入手。那我们不妨以另外两个基本事实为切入点，看看能否有所改善。

（1）每个项目中都会有一些工具用来处理若干组件公用的业务逻辑，比如说特定时间日期的转换等，这些方法通常分布在普通的ts 文件或者service.ts 里面。

（2）Angular 项目中会用到大量的pipe，pipe 实际上就是一个处理输入输出且逻辑稳定的函数看到这两点，相信你的脑海中可能已经浮现出具体的函数名，我们就从这部分代码开始。

如何开始？

创建一个spike

所谓的spike（中文可翻译为【轻轻地刺】），是指当我们面临一个不太熟悉的技术领域的时候，先抛开目前已有的东西，迅速从零开始建立一个demo，以考察我们的方向是否可行。每个人在日常工作中应该都有过运用spike 解决问题的经历，尤其是在进行带有技术预演性质的工作时。只是可能很多人不知道该如何来描述这个过程。

回到正文，大多数团队面临的情况可能是，我的代码目前运行良好（至少not bad），每个迭代有大量的需求要做。团队里面一直没有写测试的传统，也没有人关心。要在这样一个快速演进的项目中集成自己不太熟悉的技术领域，确实是一个麻烦事。因此，我们先来做一个spike。用ng-cli 新建一个项目完成我们对Angular 单元测试的探索。在spike 当中，我们可以抛开所有规范、设计层面的约束，只是为了探索和验证。

首先，我们用ng-cli 创建一个新的项目，这个操作实在是再简单不过了：

ng new spike-test

然后：

cd spike-testng test

就像上面那样，我们已经完成了一个最简单的包含单元测试的项目，这个过程大概只花了你3分钟的时间？现在我们把这个项目拆开看看，以便把必要的信息提取出来集成到我们已有的项目中。

通过spike查看测试的组成

主要来看看app.component.spec.ts 这个文件。

从这个测试文件中，我们可以看到，要完成一个测试，首先要引入一些跟测试相关的包和被测试的组件（或是服务、管道甚至普通的ts 文件）。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

)**

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！