重构中的测试
每当我要重构的时候，第一个步骤永远相同：我得确保即将修改的代码拥有一组可靠的测试 –> 在日常开发中，我们能够体会到修复 bug 通常是比较快的，但是找出 bug 所在却是一场噩梦
测试过程中很重要的一部分，就是测试程序对于结果的报告方式。要么变绿，要么变红，用于自我检验，否则就得耗费大把时间来回对比，这会降低开发速度 -> 测试自动化，让它们检查自己的测试结果
推荐编程方式：【测试驱动开发】做需求前，先编写一个测试 -> 编写代码使测试通过 -> 进行重构以保证代码简洁
测试部分总结
由于本书其实是一本指导重构的书，对于测试其实没有描绘那么细致，甚至我并没有感觉有很大的可行性，不知道是我个人习惯还是行业普遍性，编写单例一般只会在我用 postman 都无法调试接口的情况，比如一些定时任务，其他场景都是根据具体的需求，开发具体的接口即可
如何编写测试
使用开源框架，有清晰的输出结果，更省时间，书中作者采用的是 Mocha 框架 + Chai 断言库，例如
describe('province', function() {
it('shortfall', function() {
const asia = new Province(sampleProvinceData());
// assert.equal(asia.shortfall, 5);
// assert 断言是一种风格，或者也可以使用 js 更适合的 expect 风格
expect(asia.shortfall).equal(5);
});
it('profit', function() {
const asia = new Province(sampleProvinceData());
expect(asia.profit).equal(230);
});
});
测试的核心
测试应该是一种风险驱动的行为，目标是希望找出现在或未来可能出现的 bug（尤其注意边界情况 - 例如参数为空）；而不是测试那些仅仅读写字段的访问函数，它们太简单了，不容易出错（不要盲目写很多测试，应该把测试集中在可能出错的地方）
工作技巧
每当你收到 bug 报告，请先写一个单元测试来暴露这个 bug