如何在没有逻辑的情况下对类进行单元测试? [英] How to unit test class with no logic?
问题描述
我发现为算法编写单元测试很容易.例如，sort(List)，很容易写出这样的测试:
I find it easy to write unit tests for algorithms. For example, sort(List), it is easy to write tests like:
list = [2, 1, 4];
assert(sort(list) == [1, 2, 4]);
但我发现测试没有逻辑、没有 if 语句、只有一组调用的方法真的很难.
But I find it really hard to test methods that have no logic, no if statements, just a set of calls.
主要有 2 个示例，我想知道如何对它们进行单元测试:
There are mainly 2 examples that I'd like an answer for how to unit test them:
示例 1:
假设我有一个类负责将一些数据写入文件，但该数据是由外部函数以特定方式写入的(writeHeaderToFile、writeSerializedData和 writeEndOfFile).
Let's say I have a class that is responsible for writing some data to a file, but that data is written in a specific way by external functions (writeHeaderToFile, writeSerializedData and writeEndOfFile).
数据没有直接写入文件，所以如果数据是这样的:
The data is not written straight as it is to the file, so if data is something like:
{
list: [
"item 1",
"item 2"
],
name: "aaa"
}
这并不意味着该文件既不是该数据的纯版本(没有空格)，也不是简单的序列化版本或加密版本到文件中.实际的文件二进制文件对我来说是未知的.我所知道的是，我可以使用这 3 种方法以正确的方式写作.
That doesn't mean that the file will be neither the plain version of that data (without white spaces) nor it will be a simple serialized version or encrypted version into file. The actual file binary will be something unknown to me. All I know is that I can use those 3 methods to write in the right way.
该文件还包含一些并非直接来自这 3 种方法的其他信息，例如特定类型的标头(同样，我不知道它将如何在文件二进制文件中表示).
This file also contains some other information that doesn't come directly from those 3 methods, like a specific type of header (that again, I have no idea how it will be represented in the file binary).
那是类:
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();
}
}
对于这个，我可以做这样的事情:
For this one I could do something like this:
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();
但我没有发现它有多大价值，因为我只是断言我正在做与实施中所做的相同的事情.对我来说似乎是代码重复.
But I don't find much value in it since I'm just asserting that I'm doing the same thing I'm doing in the implementation. Seems like code repetition to me.
测试我的两个示例的正确方法是什么?
What would be the proper way of testing my 2 examples?
推荐答案
在第一个示例中，如果您编写了有问题的消息并且对您的测试覆盖率感到满意，则没有理由在 FileCreator 上重现该测试逻辑.您只需要测试 FileCreator populateFileWithData 方法以确保文件已写入并且锁定机制可能有效.
In the first example, if you wrote the messages in question and satisfied with your test coverage, there's no reason to reproduce that testing logic on FileCreator. You just need to test the FileCreator populateFileWithData method to make sure the file is written and maybe that the locking mechanism works.
你说得对，你的最后一个测试相当简单.我很想省略写它.但这取决于.是否有可能有人会出现并注释掉其中一个面板构造函数?您是否有其他测试可以识别此类问题?
You are right, your last test is rather trivial. I'd be tempted to omit writing it. But it depends. Is it likely that someone might come along and comment out one of those panel constructors? Do you have other tests that would identify such a problem?
这篇关于如何在没有逻辑的情况下对类进行单元测试?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
