单元测试不是测试，而是开发的辅助工具，最好不当成测试。单元测试追求业务逻辑的覆盖率，最好不要追求代码覆盖率，否则就不方便重构了。，
全栈工程师诚如作者所说。但拿开发者来说，也需要他关注业务，包括用户，价值，场景，满意条件，能就开放性问题进行交流，否则如何开发出切合业务的软件。再者说，开发人员也要有功能测试的能力，否则，如何知道一个功能开发完成了，难道真要等测试人员测出问题才知道这个功能其实没有做完？
单元测试应该在设计出一个接口时就设计单元测试用例，若发现用例数过多，则按单一职责原则重构接口，这个角度说，单元测试让重构提前了。要是完成一个类后再写测试用例，稍微有点晚。
软件可以用
写的真好，很详细，可学习操作性很强。作者的一些建议我也正在摸索着做。例如实现功能前考虑用户，价值，场景和满意(验收)条件。其实还可以加上限制依赖和假设
设计用例的维度
测试执行是为了发现问题，不是证明软件没问题
软件用的对
单元测试不是测试，而是开发的辅助工具，最好不当成测试。单元测试追求业务逻辑的覆盖率，最好不要追求代码覆盖率，否则就不方便重构了。，
全栈工程师诚如作者所说。但拿开发者来说，也需要他关注业务，包括用户，价值，场景，满意条件，能就开放性问题进行交流，否则如何开发出切合业务的软件。再者说，开发人员也要有功能测试的能力，否则，如何知道一个功能开发完成了，难道真要等测试人员测出问题才知道这个功能其实没有做完？
单元测试应该在设计出一个接口时就设计单元测试用例，若发现用例数过多，则按单一职责原则重构接口，这个角度说，单元测试让重构提前了。要是完成一个类后再写测试用例，稍微有点晚。
软件可以用
写的真好，很详细，可学习操作性很强。作者的一些建议我也正在摸索着做。例如实现功能前考虑用户，价值，场景和满意(验收)条件。其实还可以加上限制依赖和假设
设计用例的维度
测试执行是为了发现问题，不是证明软件没问题
软件用的对