过去我们一直的都在倡导著开发者需进行所谓的单元测试。
开发者测试 vs 单元测试
单元测试是个相当有效的工程实践, 这是无庸置疑的。但是, 全世界大部分的开发人员是都没有在写单元测试的。
为什么 ?
主要的原因如下:
- 粒度过小的单元测试用例是很难进行维护与扩展的:
针对这个问题, 我们必需要有个轻量级、可视化的方法, 可协助开发人员找到真正值得进行测试的关键路径。
只针对关键路径进行测试用例的开发, 才不会形成粒度过小的测试用例; 粒度过小的测试用例将会难以的进行维护, 最终只好宣布放弃。
Story 场景树是个相当好的方法,可协助开发人员找到真正值得进行测试的关键路径。

2. 单元测试的写法尚不够简洁:
单元测试往往都会写得过于的片断, 无形中就会很容易的遗漏掉应该测试的场景。
针对这个问题, Property-Based Testing 是个相当好的解决方案。
Property-Based Testing 能以 @given 的方式生成测试数据; 而能以测试数据驱动的方式, 在单一的测试用例中完成多个不同的场景的测试; 使得开发人员能以少量的测试代码, 完成更有效、更完整的测试场景的测试。
@given(st.lists(st.integers()))
def test_sort(XS):
sorted_xs = quicksort(XS)
assert isinstance(sorted_xs, list)
assert Counter(XS) == Counter(sorted_xs)
assert all(
x <= y for x, y in
zip(sorted_xs, sorted_xs[1:]
)
3. 单元测试的 Mock 并没有发挥其应有的功能:
单元测试的 Mock 的机制, 并没有能真正的高效、有效的使得开发人员在开发的阶段, 就能得知自身代码的变更对其他开发人员所负责的代码的影响。
针对这个问题, Contract Testing 是个相当好的解决方案。


单元测试启蒙了我们应该如何的去开发高质量的代码。
开发者测试; Story 场景树, Property_Based Testing , Contract Testing; 使得我们能真正高效率、有效的去开发高质量的代码。