时间戳

首页 > 解决方案 > TDD：在实现另一种（公共）方法之前无法测试一种方法的行为，反之亦然

unit-testing - TDD：在实现另一种（公共）方法之前无法测试一种方法的行为，反之亦然

问题描述

我同意这样的观点，即在测试时，我们应该使用公共 API 来确保我们的测试不会脆弱。IE。不要测试实现，测试行为。

想象一下我的公共 API 将有两种方法或功能的情况。一种是更新内部私有状态的命令方法。另一种是查询方法，它从这个私有状态中检索信息。我不想仅仅为了测试而公开私有字段。

挑战在于我如何在确认一个需要另一个的行为时开始编写我的测试，同时遵循 TDD 方法。

让我们想象一个这样的场景：

class Manager:

    def Manager():
        _reserved_resources = []

    def reserve_resource(id):
    # Creates a new resource and reserves if none exist in the pool, or reserves an existing one. Does not return anything.

    def retrieve_reserved_resource(id):
    # Returns a reserved resource, or returns None if not previously reserved.

如果我使用公共 API，则在实现retrieve_reserved_resource之前，我无法测试reserve_resource的行为。而且我无法测试retrieve_reserved_resource是否具有正确的行为，直到实现reserve_resource。

如果我的第一个测试是：

def test_reserve_resource_when_no_resources_exists_creates_a_new_resource()

当retrieve_reserved_resource尚未实现时，如何确认此行为。

我是否只是像实现了retrieve_reserved_resource一样编写测试，因此，当测试变为绿色时，我将拥有这两种方法的基本实现？

这对于 TDD 来说是非常具体的。也明白这是一个人为的例子，但希望它能澄清问题。基本上这是一个先有鸡还是先有蛋的场景，其中命令方法和查询方法都需要彼此确认它们的行为。那么从哪里开始呢？

标签： unit-testingtddpublic

解决方案

我的启发是“先读后写”——如果你不能测量被测代码的行为，你就不能“驱动”任何设计，或者任何实现。

所以第一个测试都将是“我在最简单的情况下测量什么”的变体？

m = Manager()
assert m.retrieve_reserved_resource(12345) is None

然后，当我们对这些测试感到满意时，我们会继续测量在稍微复杂一点的情况下会发生什么。

m = Manager()
m.reserve_resource(12345)
assert m.retrieve_reserved_resource(12345) is not None

推荐阅读