开发者测试; Story 场景树、Property-Based Testing、Contract Testing

过去我们一直的都在倡导著开发者需进行所谓的单元测试。

开发者测试 vs 单元测试

单元测试是个相当有效的工程实践, 这是无庸置疑的。但是, 全世界大部分的开发人员是都没有在写单元测试的。

为什么 ?

主要的原因如下：

1. 粒度过小的单元测试用例是很难进行维护与扩展的：

针对这个问题, 我们必需要有个轻量级、可视化的方法, 可协助开发人员找到真正值得进行测试的关键路径。

只针对关键路径进行测试用例的开发, 才不会形成粒度过小的测试用例;  粒度过小的测试用例将会难以的进行维护, 最终只好宣布放弃。

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; 使得我们能真正高效率、有效的去开发高质量的代码。