各位 V 友们对 单元测试 有什么心得？

题主是搞(Pai)(Huang)(Pian)的，最近做单元测试的话，很容易就陷入一些思考，这样做对不对呢？所以就想到上来问问 V 友，借鉴学习。我个人比较强迫症，追求自己写的代码完美。

答:PHPUnit 可以试试
答:不要问泛泛而谈的问题。
答:我不知道对不对，反正写了单元测试以后我发现效率比以前高了不止一两倍。
有人说写了更多的代码。但是我想说的是，写点儿代码把手动验证的流程交给计算机来做，并且可以快速重复做很多遍，到底是省事儿了还是麻烦了自己琢磨。
答:首先要明确你为什么要写单元测试？你希望它解决什么问题？回答了这个问题之后写测试的思路可能就比较清晰了

对于我来说，单元测试主要的作用是提高代码的可维护性，确保以后修改代码能及时发现影响范围，重构是否破坏了原有的业务逻辑？修改是否影响到了其他业务逻辑？如果程序写完之后就不需要维护了，那就完全没必要写测试

那么由此再说说我的一些体会

1. 测试代码要简洁清晰
测试代码比业务代码更追求可读性，它唯一的用户就是维护者，不需要考虑性能之类的问题，而混乱的测试代码比混乱的业务代码更让人不想维护。一个测试应该遵循三段论: 初始化场景，执行被测试方法，验证执行结果，所以一个理想的测试方法应该只有三行（ clean code 书里已经说得很清楚了）

2. 测试范围
所有 public 方法，重要的 protected 方法，几乎不测试 private 方法
public 方法是类的公开 api ，可能被各种业务调用，所以一定要保证任何改变了 public 方法行为的修改都被检查到
同样 protected 方法是对子类公开的，对于被很多子类使用的 protected 方法，需要确保对它的修改不影响子类的行为
private 方法很不稳定，可能经常被修改，它只在类内部被调用，对 public, protected 方法的测试已经把它覆盖到了

3. 针对方法特性测试，而不是针对实现测试
可以把被测试代码当成一个黑盒，给它一个需求要求的输入，然后验证它是否返回了期待的输出。不需要去验证它在处理这个东西的过程中干了什么，没必要，因为具体实现可能会因为各种原因而修改，我们只要确保测试能检查到修改后的程序是否满足需求要求就行了
同时，又要保证测试覆盖了方法的所有的需求点，包括异常情况都需要写测试覆盖到。一个测试用例写一个测试方法
比如这个测试文件，这些测试方法都只在测一个 public 方法（不要吐槽方法命名...）


4. 其他
- PHPUnit 的 DataProvider 慎用，不是它不好，是它很容易就搞出一些特别难维护的测试代码，比如把正常流程和异常流程的测试都放到一个测试方法里，然后用 DataProvider 提供的参数来进入不同的测试流程，整个测试方法一大坨， DataProvider 里面的数据又是一大坨，看得人想死
- 很多时候写测试会反向地要求你优化你的程序设计，最常见的例子就是依赖注入了，这里是之前 google 的一个 guide ， http://misko.hevery.com/attachments/Guide-Writing%20Testable%20Code.pdf
答:我感觉楼上的都是复制粘贴的，没必要看。
DataProvider 该用还是可以用的，个人觉得很好用，数据容易维护。
单元测试用什么写，怎么写不重要，既然是白盒测试，衡量标准自然是代码覆盖率，这个覆盖率你应该有个预期，覆盖核心代码还是全部代码。
至于实施上，看你是设计驱动的还是开发驱动的，自己调节。
不要管那么多没什么用的，关键在于你写单测的态度和出发点是什么。
有上来问的时间，足够你写好多单测了。