LLT做不好的原因会是啥

问题：

LLT做不好的原因会是啥？

回复：

首先说一下思想层面的问题，没有测试的代码是不完整的，那这里就有一个问题，为什么我们写完代码一定要写测试呢？

在回答这个问题之前，我们先问一下自己，我们写完这个代码是不是写完就以后不管了，如果不管了那就没必要写测试。

只要以后还想维护，那么测试代码是必不可少的，第1个原因，你的代码可能会被别人去接手，别人并不懂你的思路，那么测试案例就是别人理清你代码逻辑的重要依据，同时也是在别人修改你代码的时候的一个重要验证标准。第2个原因，即使代码是由你自己来维护的，之前写的代码，过段时间以后再去看的时候，你可能会感觉比较陌生了，因为遗忘是有规律的。

所以我们会看到让自己哭笑不得的一幕：

有的程序员骂看到的代码非常烂，结果查一下历史记录，是他自己两三年之前写的。

这种现象并不是孤立的，因为随着时间的推移，我们经验的增长，技术水平的不断提高，我们的眼光也会随之升高，再回头去看我们原先的代码的时候，就会发现那些代码比较弱智，这是程序员的人之常情。

在这种情况下，我们自然的想进行重构，调整以前的代码，如果以前有测试案例的话，我们会非常从容，继而省去不少时间的开销。

其次是技术层面的问题，因为测试代码跟我们实际的生产代码技术的侧重点是不一样的，测试代码这一部分我们需要做一些模拟数据，同时需要测试的框架。

测试框架的作用，一是帮助我们完成测试的自动化自动验证，如成功还是失败，同时也提供数据模拟的机制。

关于数据模拟部分，我们需要寻找测试替身，测试替身有很多种类：

其中最简单的就是Dummy, Dummy的模式最简单，我们可以把它理解成固定的数据提供模式，比如随便返回一个默认值。

另一个叫stub，它是在Dummy的基础上添加了简单的逻辑，提供了不同的输出，比如说根据输入的参数来返回不同的默认值。

再一个是spy，它可以捕获和监听测试对象的状态，以获得更高级的状态验证，比如可以用它来监听某个函数是否被调用了。

再一个是mock, mock的功能比上面的几个都要强大，它既能够提供定制的输入又可以进行监测。

最后一个是simulator即仿真器，仿真器相对来说比较复杂，它是一个全面的软件组件，它比上面几种方式都要接近真实的数据状态。但是仿真器如果没有现成的，相对来说开发难度比较大。

接下来说一下测试代码编写的时机。

第1个时机是在代码创建之初，或者在重构之前要先添加测试框架支持。这个时候的添加效果，我们希望可以有一个hello world的测试案例输出。

第2个时机是代码成型之后再进行测试案例代码的添加，如果代码还没有成型就去添加测试案例，因为代码的执行路径还没有确定，这会导致你不断的修改你的测试案例代码，不必要的工作量。当然这个地方有一个疑问点，就是如果你采用的是tdd (测试驱动开发), 那就另当别论，因为这种方法是要求先写测试案例, 再填充生产代码。

最后一个是测试代码的复杂度，这个看似容易理解，但很多人经常犯的一个错误。测试代码要追求平铺直叙，复杂度越低越好。除非万不得已，不要有任何的条件判断，比如像if else switch这种条件判断就免了，条件判断会增加你测试代码的复杂度，破坏测试单元的目标单一性。