在做TDD时,我应该对"做最简单可能的工作"有多严格

Question

对于TDD,你必须这样做

1. 创建失败的测试
2. 做最简单的事情可以通过测试
3. 添加更多测试变体并重复
4. 当模式出现时重构

有了这种方法,你想要覆盖所有的情况(至少在我脑海中浮现),但我想知道我是否在这里过于严格,如果有可能"提前思考" 一些场景而不是简单发现它们.

例如,我正在处理一个文件,如果它不符合某种格式,我会抛出一个 InvalidFormatException

所以我的第一个测试是:

@Test 
void testFormat(){
    // empty doesn't do anything nor throw anything
    processor.validate("empty.txt"); 
    try {
        processor.validate("invalid.txt");
        assert false: "Should have thrown InvalidFormatException";
    } catch( InvalidFormatException ife ) {
        assert "Invalid format".equals( ife.getMessage() );
    }
 }

我运行它并失败,因为它不会抛出异常.

因此,我想到的下一件事是: "尽可能做最简单的事情",所以我:

public void validate( String fileName ) throws InvalidFormatException {
    if(fileName.equals("invalid.txt") {
        throw new InvalidFormatException("Invalid format");
    }
}

卫生署!(虽然真正的代码有点复杂,我发现自己做了几次这样的事情)

我知道我最终必须添加另一个文件名和其他测试,这会使这种方法变得不切实际,这将迫使我重构一些有意义的东西(如果我理解正确是TDD的重点,发现模式的用法推出)但是:

问:我是否过于字面意思"做最简单的事情......"的事情？

Answer 1

如果你对它感到满意,我认为你的方法很好.你没有浪费时间编写一个愚蠢的案例并以愚蠢的方式解决它 - 你写了一个真正理想的功能的严肃测试,并让它传递 - 正如你所说 - 最简单的方法可能工作.现在 - 以及将来,随着您添加越来越多的实际功能 - 您将确保您的代码具有在一个特定格式错误的文件上抛出正确异常的所需行为.接下来要做的就是让这种行为成为现实 - 你可以通过编写更多测试来推动这种行为.如果编写正确的代码变得比再次伪造它更简单,那就是当你编写正确的代码时.这种评估因程序员而异 - 当然有些人会认为时间是第一次失败的测试.

你正在使用非常小的步骤,这对我和其他一些TDD来说是最舒适的方法.如果你对更大的步骤感觉更舒服,那也没关系 - 但是知道你可以在那些重大步骤绊倒你的那些场合总是回到更细粒度的过程.