语言无关 – 在做TDD时,我应该做多少严格的“做最简单的事情呢”

对于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的意义，发现模式的用法揭幕)但是：

问：我是否采取太字面上的“做最简单的事情”的东西？

我觉得你的方法很好，如果你很舒服。你没有浪费时间写一个愚蠢的案例，并以一种愚蠢的方式解决它 – 你写了一个严重的测试，以获得真正的所需功能，并使其通过 – 就像你所说 – 最简单的方法，可能会有效。现在 – 将来，随着您添加越来越多的实际功能 – 您确保您的代码具有将特定格式错误的文件抛出正确异常的所需行为。接下来是要使这个行为真正 – 你可以通过编写更多的测试来驱动它。编写正确的代码比假的更简单，那就是写正确的代码。这个评估在程序员之间有所不同 – 当然有些人会决定时间是第一次失败的测试。

您正在使用非常小的步骤，这对我和其他一些TDDers来说最为舒适。如果你对更大的步骤更舒适，那也没关系，但是你知道，当大步走上你的时候，你总是可以在更细微的过程中回归。