TDD的测试文档化

在上一篇文章中，我们详细介绍了如何使用ContainerProvider来替代相应的Config相关API。

在TDD中的测试是我们达到里程碑(MailStone)。然而，需要注意的是, 这种测试并不是文档。测试应该是文档, 而文档不是我们实现的过程。所以我们需要对我们的测试用例进行一些文档改造，以确保文档和代码之间的匹配，才能更好地理解和维护我们的软件系统。

首先第一个就是关于命名不一致的情况,这也是由于之前重构测试用例代码导致的。

观察下面这段测试用例:

@Test
public void should_bind_type_to_a_class_with_default_constructor() {
    setup();
    Component instance = new ConstructorInjectionProvider<>(ComponentWithDefaultConstructor.class).get(context);

    assertNotNull(instance);
}

上面这个测试描述是

should_bind_type_to_a_class_with_default_constructor

这段代码是从 config 的角度来考虑的。然而，现在我们应该从constructProvider的角度来审视问题。所以我们需要对此进行一些修正, 所以将上面的测试描述改成

should_call_default_constructor_if_no_inject_constructor

然后我们继续看下面这个测试描述, 同样也是从config的角度来看的。

public void should_bind_type_to_a_class_with_inject_constructor() {
    setup();
    ComponentWithInjectConstructor instance =
            new ConstructorInjectionProvider<>(ComponentWithInjectConstructor.class).get(context);
    assertNotNull(instance);
    assertSame(dependency, instance.getDependency());
}

我们将其改成:

should_inject_dependency_via_inject_constructor

改完这些不一致的行为, 从文档角度上来看, 我们可以继续对这些测试进行进一步的分组。

@Nested
class Injection {
    @Test
    should_call_default_constructor_if_no_inject_constructor;

    @Test
    should_inject_dependency_via_inject_constructor;

    @Test
    should_include_dependency_from_inject_constructor;
}

@Neseted
class IllegalInjection {
    
}

然后依次类推, 我们可以对methodInject和fieldInject进行分类, 同时让命名保持一致

//比如在constructorinject的injection中, 我们有这样一个测试方法
should_include_dependency_from_inject_constructor;

//那么在methodinject中我们也保持一致, 讲下面这个方法名称保持一致
should_include_field_dependency_in_dependencies

should_include_dependency_from_filed_dependency

经过这些步骤我们让我们的测试用例描述的更加一致``