很多人写代码的时候会急着把各个部分连接起来，但却忽视了核心业务部分的构建，这样做造成的结果就是严重的耦合，这也是很多后续问题产生的根源。
来自：02 | 实战：实现一个 ToDo 的应用（下）
5 人划过
为了写测试，首先“驱动”着我们把需求分解成一个一个的任务，然后会“驱动”着我们给出一个可测试的设计，而在具体的写代码阶段，又会“驱动”着我们不断改进写出来的代码。把这些内容结合起来看，我们真的是在用测试“驱动”着开发。
来自：17 | TDD 就是先写测试后写代码吗？
5 人划过
一条设计规范：Repository 的问题以运行时异常的形式抛出，业务层不需要做任何处理。
来自：01 | 实战：实现一个 ToDo 的应用（上）
5 人划过
你要想写好单元测试的话，最好能够将代码和测试一起写
来自：08 | 单元测试应该怎么写？
5 人划过
另一方面，还让业务核心代码对第三方代码（也就是 ApplicationContext）产生了依赖。
来自：13 | 在 Spring 项目中如何进行单元测试？
4 人划过
断言，说白了就是拿执行的结果和预期的结果进行比较。如果执行一个测试连预期都没有，那它到底要测什么？所以，我们可以说，没有断言的测试不是好测试。
来自：04 | 自动化测试：为什么程序员做测试其实是有优势的？
3 人划过
*精彩内容为该课程各文章中划线次数最多的内容
讲师
郑晔
开源项目 Moco 作者
编辑推荐
讲师的其他课程
看过的人还看了
