之前拜读《测试驱动开发》觉得这种方法真了不起，之后在工作中也是一直坚持实践。实践TDD真的可以让开发效率变快。现在写代码，早就把Postman之类的工具抛到脑后了，完全通过单元测试来构建可靠的应用。个人感觉使用TDD是一个先慢后快的过程，开头可能会慢一点，但是越往后测试越多，代码写的越快，真的很神奇。

对于tdd的理念非常认可，但实际工作中接触的很多都是老项目，一个方法几百行起步，各种反射、静态方法，想写测试感觉都无从下手，更别说tdd落地。希望老师可以讲讲老项目如何开展测试工作

🤔☕️🤔☕️🤔 * TDD带给我的最大改变，那就是先去设定验收的形式和手段，即确定验收的边界，然后整个实现都在趋近这个边界。这种方法刚开始用，很难受，原因在于自己经验不足，不知道怎么验收自己的成果。随着经验的增加，知道如何准确验收自己的成果，就会自然而然TDD。如果是分派任务给大家，个人实践下来，TDD也是优质武器，就是在分配前，对将来交付的内容有验收的预期，会极大提高交付的质量，更不会在交付时带来惊吓级别的惊喜。 * 所以说，TDD在开发初级，会有难受，在开发中级，会自然形成。如果某个所谓的资深，还在说TDD的优劣势，尤其各种不对付，那么大概率他没有体验过一把交付无缺陷的代码，更大概率他卖下过巨量技术债务，要么他本人还在还债，要么已经把债务转嫁给某些无辜开发。

很硬核 还配有字幕 感觉可以不用录音 文字加视频就好了

内容非常的不错，在工作中也一直在实践，并尝试跟测试用例结合，以达到减少手动测试的目的。 对于这个学习形式，个人认为音频加视频的形式，有点打断学习的体验了，感觉可以都用视频的形式就好，不然要一直音频和视频之间切换，体验感不佳

非常高兴徐老师能给大家一个如此基础又如此重要的课程，几乎所有公司都在强调单元测试的重要性，但是我看过很多代码，基本都没有单元测试，好一点的团队是刚开始有单元测试，后面就没有继续维护了。大家都这么重视单元测试，但是为什么都没有坚持下来呢？主要是单元测试成为了项目开发的累赘，没有用TDD。如果是先写代码，再写单元测试，很容易给人一种多余的感受，而且为了测试而测试，就会导致测试无群无尽，甚至连整数的边界都纠结要不要一块测试了。如果用TDD，从test case的角度去设计测试，就不会存在这样的问题。 文章的一个观点非常重要，我们并不是写测试想取代测试人员，而是我们换了一种高效的测试方法而已。我们让测试粒度更细，测试自动化，提高测试的效率。无论如何程序员自己的白盒测试都是要做的，那我们使用TDD这种好的工程实践方法，可以使我们变成高效可靠的程序员。

请问课程中有springboot下tdd落地的内容吗？

工作快一年了，刚开始就知道了TDD，但是一直没有得其要领。后面也接触到了alpha测试，有了自己对开发测试的思考，但始终没有找到一个最佳实践，而自己对测试的理解也在一次次的开发中不断的变化。一开始初生牛犊不怕虎，看到质量较差的代码就想重构、重写，到后面逐渐不敢去碰了，保证自己的代码质量就行了。看着那些老代码，有种心有余而力不足的感觉。自己开发的代码一般都会有测试代码的覆盖，但并不是按照TDD的流程，交付时间又紧张，如果不写测试用例，就能更早是转测代码，有时也会怀疑自己写这些测试用例真的有意义吗，是不是只是自己的自我感动罢了？这次课程，感觉是打了瞌睡来了枕头，非常感谢老师和极客时间这个平台，希望未来自己能真正用好TDD，提高代码质量。

老师讲的这三类场景日常前端开发中也会碰到，甚至更频繁，比如页面的展示就可以算是「跑一下」验证。请问老师对于前端该写哪些范围的测试，有建议或者单独的章节来讲吗？