unit-testing - 如何对没有逻辑的类进行单元测试？

Question

我发现为算法编写单元测试很容易。例如，sort(List)，很容易编写如下测试:

list = [2, 1, 4];
assert(sort(list) == [1, 2, 4]);

但我发现很难测试没有逻辑、没有 if 语句、只有一组调用的方法。

主要有 2 个示例，我想知道如何对它们进行单元测试:

示例 1:

假设我有一个类负责将一些数据写入文件，但该数据是由外部函数以特定方式写入的(writeHeaderToFile、writeSerializedData和 writeEndOfFile)。

数据并没有直接写入文件，所以如果数据是这样的:

{
    list: [
        "item 1",
        "item 2"
    ],
    name: "aaa"
}

这并不意味着该文件既不是该数据的普通版本(没有空格)，也不是简单的序列化版本或文件加密版本。实际的文件二进制文件对我来说是未知的。我所知道的是，我可以使用这 3 种方法以正确的方式写作。

此文件还包含一些不是直接来自这 3 种方法的其他信息，例如特定类型的 header (同样，我不知道它将如何在文件二进制文件中表示)。

那是类:

class FileCreator {
    populateFileWithData(File file, Data data) {
        doBlockWithLock(file, {
            Header header;
            header.format = SomeFormat;
            header.version = SomeVersion;
            writeHeaderToFile(file, header);

            writeSerializedData(file, data);

            writeEndOfFile(file);
        });
    }

    // Private
    void doBlockWithLock(File file, Lambda block) {
        file.holdWritingLock();
        block();
        file.releaseWritingLock();
    }
}

示例 2:

class Controller {

    var screenOne = new ScreenOne();
    var screenTwo = new ScreenTwo();
    var screenThree = new ScreenThree();

    void reloadButtonWasClicked() {
        screenOne.reload();
        screenTwo.reload();
        screenThree.reload();
    }
}

对于这个我可以做这样的事情:

var mockScreenOne = Mock<ScreenOne>().reload.expectOneCall();
var mockScreenTwo = Mock<ScreenTwo>().reload.expectOneCall();
var mockScreenThree = Mock<ScreenThree>().reload.expectOneCall();

Controller controller = new Controller();
controller.screenOne = mockScreenOne;
controller.screenTwo = mockScreenTwo;
controller.screenThree = mockScreenThree;

controller.reloadButtonWasClicked();

mockScreenOne.verify();
mockScreenTwo.verify();
mockScreenThree.verify();

但我没有发现它有多大值(value)，因为我只是断言我在做与在实现中所做的相同的事情。对我来说似乎是代码重复。

---

测试我的 2 个示例的正确方法是什么？

Answer 1

在第一个示例中，如果您编写了有问题的消息并对您的测试覆盖率感到满意，则没有理由在 FileCreator 上重现该测试逻辑。您只需要测试 FileCreator populateFileWithData 方法以确保文件已写入并且锁定机制可能有效。

你是对的，你的最后一个测试是相当微不足道的。我很想省略写它。但这取决于。是否有人可能会出现并注释掉其中一个面板构造函数？您是否有其他测试可以识别此类问题？