大家好，我来了~
今天这一章的主题是务实的入门套件。这本书讲的内容有点太多，可能一时间不知道从哪里下手，所以，作者特意选了三件务实的入门套件。
而且和语言、方法论、技术栈这些都不管，属于最基本最基础的部分，大概是地基的角色。
他们分别是：
- 版本控制
- 回归测试
- 全面自动化
版本控制
之前的内容里有说过，应该把项目中用到的所有东西都加入版本控制中。
这样做还有一个隐形的好处，它能让我们不依赖于某台特定的开发电脑，并且谁都不敢轻易地动它。
有了版本控制后，一起都变得简单了。那台电脑想要，就克隆一份下来就好。
另一个好处是，使用版本控制可以推动测试和部署的自动化。
每一个commit提交，都可以触发自动的测试和部署。
回归测试
务实的程序员会对程序进行冷酷无情的持续测试。相比于被别人发现bug，自己先发现要好得多。
作者说，一个好的项目，测试的代码甚至要比工作代码还要多。
并且测试需要自动化进行，测试的环境也要尽可能的和生产环境一致，不一致的地方都有可能是bug的温床。
单元测试
单元测试是后续所有测试的基础。它就是基于单一模块，单一功能的测试。
集成测试
多模块间的配合测试，它可以用来测试，各个模块的合同是否被很好的贯彻。
认证与验证
对于权限的认证，以及如果有用户输入的情况，对用户的输入进行验证。
性能测试
又或者叫压测，测试系统的性能瓶颈。
测试测试
我们无法写出完美的程序，我们也同样写不出完美的测试。
所以测试本身也需要测试，有一种套娃的感觉。
这种测试通常是通过刻意引起bug，看看我们的测试是否能够捕获到这个错误。
彻底地测试
有一些工具，可以检测到我们的测试覆盖的代码量。通常很难达到100%，但多少可以作为一个参考。
但也仅仅是参考而已，即便达到了100%的代码覆盖量，也不一定表面，程序就没有bug了。
同一段代码在不同状态下，表现也可能完全不同。
比如下面这个方法，可能你运行100次都是OK的，只有在a+b等于0的时候，才有可能出错。
int test(int a, int b) {return a / (a + b);
}
所以，相比于代码覆盖率，状态覆盖率是更重要的。
这时候就需要“基于属性的测试”出场了。
让计算机生成批量的测试数据，来帮我们找到那些边界状态。
永远只发现bug一次
这是一条很朴素很管用，但是实际工作中却很少严格执行的建议。
就是每发现一次bug，就新写一个可以捕获到这个bug的测试，并在之后的每一次测试中，都加上它。
不论开发人员多么信誓旦旦地承诺，这个不会再发生了，都没有用，它已经会再次发生的。
所以，要让一个bug被发现的第一次，也成为它被发现的最后一次。
全面自动化
上面提到了这么多测试，如果都通过手动执行，会不会感到很崩溃？会不会完全不想试试看？
所以，让测试自动化，就是很重要的一步。
当然除了测试的自动化以外，部署也需要自动化。
所有固定流程的重复，都要想办法，让它们自动化。
人不是机器，人不适合做这种重复的工作，因为人不可靠。没办法像机器一样，每一次都一模一样。
作者说，他之前到过一个团队里，团队所有成员都使用了相同的IDE，然后每个人都有一本手工配置说明书，比如，先单击这里，然后把这个拖到那里，然后双击这个……
但是，最后总是时不时发现，同一段代码在A的机器上可以，在B的机器上不行的这类问题。然后仔细寻找原因后，发现多半是大家某个东西的版本不一致。
而这种事情，交给机器做，肯定会一模一样。而且，还可以一键升级。
所以，不要使用手工程序。
以上，就是作者提到的务实三件套，环环相扣，少一环都不行。除了第一个相对简单外，剩下的两个可能是大部分项目或团队有所缺乏的。需要刻意地补上才行。
特别是想想，测试的代码可能要比开发的代码还要多这件事，就挺令人绝望的。
出来混，总是要还的。
不妨从下一个方法，下一个bug开始补上吧。
