非常认同之前听到的一句话，单元测试不是为公司写的，而是为自己写的。 在公司都不写单元测试的情况，你写了，差距就产生了，你进步得越快，就能越早脱离不好的公司，至少我认为，单元测试都不愿意写的公司绝对不是好公司

一顿操作猛如虎，如此顺滑，舒适感爆棚

从代码之丑入坑，从一追到四，期待老师的新课！

我每天学一讲，20天以后会不会成为高手中的高手

看到这么理解测试的开发，真是很难得，不仅仅是理解，而且理解的相当到位。 首先，开发和测试是互补的，开发做白盒测试，测试做探索性测试、场景测试等； 其次，开发的出发点是逻辑实现的质量保证，测试的出发点是业务场景的质量保证，所以角度不同，测试点也不一样； 然后，开发和测试可以互补，比如开发提醒测试应该多关注哪部分测试内容，测试可以提供用例给开发，帮助提前考虑各种场景； 总之，开发同学应该尽可能的提高提测质量，这样可以让测试同学可以专心的做好自己应该保障的那部分质量，而不是在一些很简单很明显的问题上疲于奔命。

背景：从事数仓开发，没有对应的测试人员，也没有使用过测试框架。一般都是自己写测试脚本进行比对 测试后，清理会延迟做，因为一天的数据对，不代表每天的数据对，备份数据会保留一段时间。 问题： 1.命名比较随意。 2.测试有时候不是独立的 3.全面性比较难做到，第一，有可能是开发人员对所有的业务场景没有全面了解。 第二呢，是用户本身对业务场景没有做到全面了解

赞，老师为单元测试的痛点指出了明路。 我们的系统现在全是 static 方法.... 只能在外围做一些接口测试 ，非常痛苦。

从「10x程序员工作法」到「代码之丑」然后来到了「程序员的测试课」，昨天又情不自禁把「软件设计之美」纳入学习中。 非常喜欢郑老师的风格。案例生动，简单意骇。从10x到代码之丑，明显发现了自己的问题。原来自己虽然很努力学习。但一直在错误的道路上。感谢老师提供了一条清晰明确的道路。对未来从此不再迷惘。

老师出品，必属精品，十分推荐。 郑老师前三个专栏都买了，都是很早读完的，停不下来没有束之高阁。有的还读了好几遍。

终于遇到个能理解测试的开发了，有时候提交的东西都是一堆明显问题，此时修改来修改去，真的留给测试人员专心去想，专心去测的时间已不多了