摘要：
对一些困难的单元测试场景提供了解决方法 阅读全文
摘要：
在编写业务代码前，先考虑如何编写测试，再编写业务代码，这种开发方式称作：TDD test-driven development。 使用TDD的主要优点 就通常的单元测试而言，最为明显优点就增强了我们对代码按照设计运行的信心。 而TDD，由于是在编写业务代码提前设计，可以说，这些单元测试就反映了业务需 阅读全文
摘要：
进行重构以使得代码更为清晰 单元测试可以有效的支持重构，在单元测试保障下，可能的错误会因单元测试的存在而被及时识别。 重构的范围比较大，这里仅说明方法级别的重构。 方法级别的重构的原则是将复杂的，能够隔离的逻辑单独提取，给与明确的方法命名，保证方法内的逻辑简洁，以调高代码的易读性和易测试性。 在进行 阅读全文
摘要：
很多情况下，代码需要与外部依赖打交道，如一个REST地址，数据库链接、外部IO等；这些依赖有些速度过慢、有些不够稳定，不符合单元测试要求的快速、可重复等原则性要求，因此引入了Mock对象这一概念。与Mock相关的还有Stub这个单词。 stub 桩，它针对指定的输入缓存了行为 mock 模拟对象，增 阅读全文
摘要：
编写单元测试的用例是验证代码的正确性，很多情况下，我们倾向于让测试沿着主路径，也就是”happy path"前进，仅能验证代码的功能，却无法保证代码的健壮，因此本文就将解决单元测试测试什么这个问题。 在《Pragmatic Unit Testing in Java 8 with JUNIT》这本书中 阅读全文
摘要：
单元测试常见问题 单元测试对接手人没有意义 测试会间断性的失败 ”测试“并没有实际意义 测试需要过长的时间执行 测试没有有效覆盖代码 测试与实现耦合太紧密，意味着一点点调整将会导致大量测试失败 测试太复杂，需要预制太多条件 好的单元测试所要遵循的几个原则 [F]AST 快速性 [I]solate 隔 阅读全文
摘要：
主要对单元测试相关的一些方法论进行了说明，单元测试本身不难，难的是如何使团队认识、认可和执行单元测试，并产生正常的效果。 阅读全文