讲讲前端的单元测试
前言
我希望你看完这篇文章后，能够对你的开发流程有所启发，那就是我写这篇文章的初衷了。
什么是单元测试
顾名思义单元测试就是测试最小单元，我们的单元可能是一个函数，一个button的样式，一个文案等等都可能是一个单元。那么我们在做需求的时候没有必要将所有的单元都做测试，那可能测试代码要比需求代码多得多呢。我们在做需求之前需要提前想好我们的测试用例，并针对测试用例编写测试代码，然后写需求代码。
为什么做单元测试
做前端的很多人可能不会去写单元测试，认为这是一个浪费时间的事情，我们有这么多的需求，哪还有时间跟精力去编写测试代码？这么想当然没有错，但是当一个项目由多人一起维护的时候，假如A写了一个页面，B去维护A的页面加了一些逻辑，C去维护该页面再添加一些逻辑，当A再去维护这个页面的时候，可能就会发现已经不是当初他认识的代码了，函数也不是原来的语义，大部分的变量不知道干什么用的。那么A需要捋清楚B、C的逻辑，在B、C的基础上小心翼翼的编写新的需求，生怕哪一步写错，导致线上的代码出错。长此以往下去代码越来越难以维护，越来越少的人能看懂页面内的逻辑，糊墙试代码将页面堵得水泄不通！当然这是最坏的想法，我们不防往好的一方面来想，假如我们每个人的编码水平都很高，都按着规范去写代码，A写完代码，B去维护的时候将A的代码全部了解之后健壮了新的代码，C去维护的时候再把A、B的代码全部掌握后再去写代码，一个月，三个月。。。
所以依赖我们自觉去维护代码首先对我们个人能力有很大要求，其次对我们精力也是恨到的浪费。我们要时刻注意是否自己的代码影响到别人的代码。从长远考虑，单元测试是一个大型项目的必然选择。
我们讲的单元测试，只是测试代码的最小单元，一个函数就是一个单元，在这里我要提倡大家去学习一下函数式编程。
单元测试赋予我们的能力
在写这个答案之前我需要讲一下TDD（测试驱动开发）。
你问我什么是TDD？
TDD是一种思维，测试来推动整个开发的进行的思维。你在开发需求的时候或许不必写单元测试，但是你必须要懂得TDD，才能让你的代码看起来得体。
或许你到现在为止并不清楚什么是TDD，接下来我用简单的语言来阐述一下。
正如上面的例子中A、B、c遇到的问题，我们用TDD的思维来重新写这个页面。那么A在拿到需求之后首先应该考虑所需要的测试用例有哪些，然后对这些测试用例编写测试代码，接着去编写业务代码。
什么是TDD
TDD （test-driven development）
- Add a test
在测试驱动开发中，每个新特性都以编写测试开始。编写一个测试，它定义了一个函数或一个函数的改进，这应该是非常简洁的。要编写测试，开发人员必须清楚地了解该特性的规范和要求。开发人员可以通过use cases和user stories来完成这个任务，以覆盖需求和异常条件，并且可以在任何适合于软件环境的测试框架中编写测试。它可以是现有测试的修改版本。这是测试驱动开发与编写代码后编写单元测试的一个区别特性：它使开发人员在编写代码之前关注需求，这是一个微妙但重要的区别。
2、重构
在我们维护代码的过程中，必须定期清理不断增长的代码。新代码可以从方便的地方转移到它更符合逻辑的地方。重复的代码必须被删除。对象、类、模块、变量和方法名应该清楚地表示它们当前的用途，因为添加了额外的功能，会导致很难去分辨命名的意义。等到代码不断的增加会使得规范的命名和删除重复代码越来越收益。
3、开发风格转换
测试代码应该在功能代码之前去写，这是被认为有更多的好处。它能确定这个程序是为可测试而写的，因为开发者需要从一开始就必须考虑如何编写测试程序，而不是后面再去考虑。此外，写测试代码能够更深的理解需求。
