language-agnostic - 做 TDD 时我应该在 "do the simplest thing that could possible work"中有多严格

Question

对于 TDD，您必须

创建一个失败的测试

做最简单的事情来通过测试

添加更多测试变体并重复

模式出现时重构

使用这种方法，您应该涵盖所有情况(至少我想到了)，但我想知道我是否在这里过于严格，是否有可能“提前考虑”某些场景而不是简单地发现它们.

例如，我正在处理一个文件，如果它不符合某种格式，我将抛出 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

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

您正在使用非常小的步骤，这对我和其他一些 TDDers 来说是最舒服的方法。如果您对较大的步骤更满意，那也没关系 - 但要知道，当大步骤绊倒您时，您总是可以退回到更细粒度的过程。