TDD与图表

Question

我有一个绘制图表的应用程序。该图遵循某种模式，

例如，形状X在形状Y内，形状{X，Y}属于组P ...

图表可能变得庞大而复杂（想想电路图）。

为此应用编写单元测试的好方法是什么？

Answer 1

除非您真正了解将要构建的API调用的确切顺序，否则很难为这样的视觉内容编写定义的单元测试。

要像这样测试一些“视觉”，你有三个部分。

1. “尖峰”，以获得正确的外观，缩放，颜色等等。在某些情况下，这几乎是整个应用程序。

2. 对其进行“手动”测试会产生一些最终图像，以确保它们看起来对某人的眼睛是正确的。除了实际查看实际输出之外，没有简单的方法来测试它。这很难实现自动化。

3. 模拟图形组件以确保您的应用程序正确调用图形组件。

进行更改时，必须运行两个测试：API调用是否正确？那个API调用序列是否产生看起来正确的图像？

你可以 - 如果你想真正爆发脑细胞 - 尝试从你的图形创建一个PNG文件并测试PNG文件是否“看起来”正确。这几乎不值得。

随着您的前进，您的要求可能会发生变化。在这种情况下，您可能必须先重写尖峰并使事情看起来正确。然后，您可以提取API调用序列以从峰值创建自动单元测试。

有人可能认为创建尖峰会违反TDD。但是，尖峰旨在创建可测试的图形模块。您不能轻易地编写测试用例，因为测试过程是“向一个人展示”。它不能自动化。

Answer 2

您可以考虑首先将初始输入数据转换为可以测试的某种中间格式。然后将该中间格式转发到实际绘图功能，您必须手动测试。

例如，当您有一个输入百分比并输出饼图的程序时，您可能会有一个中间格式，它准确描述每个扇区的维度和位置。

Answer 3

1. 找出代码的复杂程度。
2. 将其与不可测试的视觉呈现分开
3. 测试

如果你没有任何非视觉复杂性，你就不是在编写一个程序，而是在制作一件艺术作品。

除非你使用一个可怕的错误编译器或其他东西，否则我会避免任何可以归结为'测试源代码执行它所说的'的测试。任何在功能上等同于：

的测试

assertEquals (hash(stripComments(loadSourceCode())), 0x87364fg3234);

可以毫无损失地删除。

Answer 4

您已经描述了数据模型。该应用程序可能会做一些事情，而不仅仅是在内存中存储一​​些数据。编写测试来执行应用程序的行为并验证结果是预期的。